From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | Ben Chobot <bench(at)silentmedia(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Updates, ShareLocks, RowExclusiveLocks, and deadlocks |
Date: | 2012-04-25 19:45:06 |
Message-ID: | 27303.1335383106@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> I think what you're missing here is that RowExclusiveLocks are taken by
> marking the row itself.
More specifically: row-level locks are not reflected in pg_locks at all.
A RowExclusiveLock entry in pg_locks reflects a *table* level lock,
which is taken by any INSERT/UPDATE/DELETE command on the table,
independently of how many rows it modifies (even zero). The purpose
of that type of lock is to prevent concurrent DDL changes on the table,
not to serialize the row-level operations.
There are locks that will show up in pg_locks that are taken transiently
when attempting to mark a row modified, but they don't persist after the
mark has been made, and the details have changed from time to time in
different PG versions. So I'd suggest testing it to see exactly what
you get.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Guillaume Lelarge | 2012-04-25 21:05:53 | Re: how robust are custom dumps? |
Previous Message | Ben Chobot | 2012-04-25 19:43:35 | Re: Updates, ShareLocks, RowExclusiveLocks, and deadlocks |