Re: How to get a self-conflicting row level lock?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Forest Wilkinson <fspam(at)home(dot)com>
Cc: pgsql-sql(at)hub(dot)org
Subject: Re: How to get a self-conflicting row level lock?
Date: 2000-07-08 04:40:17
Message-ID: 23719.963031217@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Forest Wilkinson <fspam(at)home(dot)com> writes:
> I'm worried about concurrent process synchronization. According to the
> PostgreSQL docs on the LOCK command, SELECT ... FOR UPDATE acquires a "ROW
> SHARE MODE" lock, which is not self-conflicting.

That doc is only telling part of the story, I guess. ROW SHARE MODE
lock on a *table* is not self-conflicting, and should not be, because
you want two different transactions to be able to acquire FOR UPDATE
locks on different rows of the table concurrently. But SELECT FOR
UPDATE also acquires a *per-tuple* lock on each selected row, and
that lock will prevent another transaction from acquiring a FOR UPDATE
lock on the same row(s). Try it and see.

The reason SELECT FOR UPDATE acquires a table-wide lock at all is
just to prevent table-wide conflicts, such as someone else trying
to do a VACUUM or DROP TABLE on that table. I suspect that it
doesn't really need to get a different kind of table lock than an
UPDATE gets, but haven't thought about the details.

regards, tom lane

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Jan Wieck 2000-07-08 11:29:17 Re: Re: [SQL] Re: [GENERAL] lztext and compression ratios....
Previous Message Tony Nakamura 2000-07-08 03:35:04 Supported Encoding