FOR SHARE vs FOR UPDATE locks

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: FOR SHARE vs FOR UPDATE locks
Date: 2006-11-30 22:06:13
Message-ID: 1144.1164924373@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs pgsql-hackers

I just realized that we have a bit of a problem with upgrading row
locks. Consider the following sequence:

regression=# begin;
BEGIN
regression=# select * from int4_tbl where f1 = 0 for share;
f1
----
0
(1 row)

regression=# savepoint x;
SAVEPOINT
regression=# select * from int4_tbl where f1 = 0 for update;
f1
----
0
(1 row)

regression=# rollback to x;
ROLLBACK

The FOR UPDATE replaces the former shared row lock with an exclusive
lock in the name of the subtransaction. After the ROLLBACK, the row
appears not to be locked at all (it is ex-locked with XMAX = a failed
transaction), so another backend could come along and modify it.
That shouldn't happen --- we should act as though the outer
transaction's FOR SHARE lock is still held.

Unfortunately, I don't think there is any good way to implement that,
since we surely don't have room in the tuple header to track multiple
locks. One possibility is to try to assign the ex-lock in the name
of the highest subtransaction holding a row lock, but that seems messy,
and it wouldn't really have the correct semantics anyway --- in the
above example, the outer transaction would be left holding ex-lock
which would be surprising.

I'm tempted to just error out in this scenario rather than allow the
lock upgrade. Thoughts?

regards, tom lane

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Robert Treat 2006-12-01 00:30:31 Re: DTrace docs, Open Items and Performance
Previous Message Tom Lane 2006-11-28 22:54:55 Re: [HACKERS] pg_dump -t broken for mixed case table names in beta3?

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2006-11-30 22:10:04 Re: little anoyance with configure
Previous Message Martijn van Oosterhout 2006-11-30 21:54:28 Re: little anoyance with configure