Re: Lock table, Select for update and Serialization error

"Albe Laurenz" <all@adv.magwien.gv.at> writes:
> You see, there is a difference. In case a) the serializable transaction
> will very likely fail if there are many concurrent changes on the table.
> In case b), the serializable transaction will always succeed, while
> all concurrent updates must wait.

The critical point here is that LOCK TABLE commands at the start of a
serializable transaction are performed *before* taking the transaction's
snapshot (the snap happens at the first regular DML command).  They not
only protect against post-snap changes as shown by Albe's example, but
against uncommitted changes that were made before transaction start
(by making the serializable xact wait until those changes are committed
or aborted before it takes its snap).

            regards, tom lane