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?
TIA,
--
Paulo Scardine
----- Original Message -----
From: "Bruce Momjian" <pgman@candle.pha.pa.us>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Paulo Scardine" <paulos@cimed.ind.br>; <pgsql-hackers@postgresql.org>
Sent: Wednesday, July 23, 2003 4:30 PM
Subject: Re: [HACKERS] SELECT FOR UPDATE NOWAIT
> Tom Lane wrote:
> > "Paulo Scardine" <paulos@cimed.ind.br> writes:
> > > - Where is the best place to put this?
> >
> > I think it would be a really *bad* idea to put it in LockAcquire; that
> > risks breaking things that you don't want broken.
> >
> > Whether it's special syntax or a GUC variable, the restriction should
> > only apply to SELECT FOR UPDATE row locks, perhaps user-commanded LOCK
> > TABLE operations, and maybe one or two other places that are known to
> > be used only for user-written operations and not for system-initiated
> > ones. Those places would need to check whether to do a conditional
> > or unconditional lock.
>
> My original idea was to have it apply only for exclusive locks. It
> seemed those were mostly the locks didn't want to wait for. Shared
> locking pg_class is something that you would want to wait for.
>
> --
> 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, Pennsylvania
19073
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.490 / Virus Database: 289 - Release Date: 16/6/2003
