Re: Lock table, Select for update and Serialization error

It is not necessary that LOCK TABLE will be the first statement.
(assuming serializable isolation level is snapshot isolation in postgres)
For serializable transaction, snapshot should be taken when the 'BEGIN'
statement is executed, and not when LOCK TABLE succeeds.
Hence, uncommitted changes should be invisible to serializable transaction.

> 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).
>
>