Re: SELECT FOR UPDATE NOWAIT - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: SELECT FOR UPDATE NOWAIT
Date
Msg-id 200307232309.h6NN9f701787@candle.pha.pa.us
Whole thread Raw
In response to Re: SELECT FOR UPDATE NOWAIT  ("Paulo Scardine" <paulos@cimed.ind.br>)
List pgsql-hackers
Paulo Scardine wrote:
> LockAcquire has a "dontWait" parameter, which do just what I want.
> 
> The executor level calls "heap_open(relid, RowShareLock)" when doing "FOR
> UPDATE"s.
> Should we define something like RowShareLockNoWait, so heap_open() or other
> lower level functions can call LockAcquire() with dontWait set?
> 
> By the way, is this kind of question on-topic for pgsql-hackers?

I think there are two issues with implementing nowait locking:

If we have special syntax for FOR UPDATE, we will need it for other
commands that need no wait behavior, and after a while they all carry
around that cruft --- SET seems easier and more useful.

Second, I don't think we want to carry around a NOWAIT boolean in all
our structures --- a SET would control it easier.  The SET can be
checked right in the lock code, and I think having it control only
exclusive locks would do almost everything we want.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Feature request -- Log Database Name
Next
From: Tom Lane
Date:
Subject: Re: this is in plain text (row level locks)