Thanks Laurenz for quick reply.
If this is the expected behavior then isn't 'Lock table' is just extra
performance penalty and achieves nothing under serializable isolation level.
The serializable isolation level in postgres is infact snapshot isolation.
Suppose a transaction T is using 'lock table' on table A and then
querying it.
Here T will be blocked untill all conflicting locks on A are released.
When there are no conflicting locks on A, T will go ahead and read data
from the snapshot taken at the T's start.
So, in short 'Lock Table' just delayed query of transaction T.
LOCK TABLE should never give you an error, except for a deadlock
resolution
error.
LOCK TABLE will just wait until there is no lock on the table that is
incompatible with the requested lock, then it will obtain the lock and
return.
LOCK TABLE does not modify tables or rows and so you cannot get a
serialization error, which is only issued when you run serializable
and try to modify a row that is newer than your transaction begin time.
On the other hand, LOCK TABLE will not necessarily prevent you from
subsequently receiving serialization errors if you do not request
an exclusive lock on the table.
Does that answer your questions?
Yours,
Laurenz Albe
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org/
