From: | "Albe Laurenz" <all(at)adv(dot)magwien(dot)gv(dot)at> |
---|---|
To: | <sudhirj(at)cse(dot)iitb(dot)ac(dot)in>, <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Lock table, Select for update and Serialization error |
Date: | 2007-05-22 06:25:15 |
Message-ID: | AFCCBB403D7E7A4581E48F20AF3E5DB202CB25FF@EXADV1.host.magwien.gv.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> As per postgres docs, 'Select for update' is used to obtain row level
> locks where as 'lock table' is used to obtain table level locks.
>
> Under serializable isolation level, select for update gives error if
> rows selected have been modified concurrently.
> but 'lock table' does not give such error even though some of the rows
> in the table are modified by concurrent transaction.
>
> Is this the expected behavior?
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
From | Date | Subject | |
---|---|---|---|
Next Message | Philippe Amelant | 2007-05-22 10:16:11 | Re: Postgresql 8.2.4 crash with tsearch2 |
Previous Message | Daniel Kastenholz | 2007-05-22 05:37:06 | Stored Procedures Performance: Java vs. PL/Pgsql |