Andrew Sullivan <[EMAIL PROTECTED]> writes:
> I think there's a reason why SERIALIZABLE could be slower, and that
> is that it's waiting on possibly-conflicting (but not actually
> conflicting) commits to happen in READ COMMITTED mode. No? Won't it
> have to check those things when it COMMITs?
SERIALIZABLE mode does not introduce any waits that wouldn't happen
anyway. It only affects what happens after you stop waiting. The
sequence is that if you go to update or delete a row, and you see
there's already an uncommitted change on the row, you have to wait
for that transaction to commit or roll back. If it rolls back,
you can proceed. If it commits, then either throw an error (in
SERIALIZABLE mode) or attempt to update/delete the newest tuple
version (in READ COMMITTED mode).
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
