From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Paulo Scardine <paulos(at)cimed(dot)ind(dot)br> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SELECT FOR UPDATE NOWAIT |
Date: | 2003-07-23 23:09:41 |
Message-ID: | 200307232309.h6NN9f701787@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-07-24 00:36:30 | Re: this is in plain text (row level locks) |
Previous Message | Bruce Momjian | 2003-07-23 23:04:40 | Re: Feature request -- Log Database Name |