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 18:16:42 |
Message-ID: | 200307231816.h6NIGgp05777@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Paulo Scardine wrote:
> (Excuse my english, my native language is portuguese)
>
> > I think I'm a quite attentive to the SQL and HACKERS list, and I see
> > requests for a NOWAIT option at least once a month, and it's growing.
> > Regards, Christoph
>
> Yes. I have done a little google about "pgsql select for update nowait" and
> find lot of people looking for this feature.
>
> If there is a lock and NOWAIT is specified, then raise error instead of
> waiting for the lock to release. We have some long distance connections that
> get very busy sometimes and is hard to distinguish between network problems
> and locked rows.
>
> Do you see it as something hard to implement? Any advice?
> Is it just to add an "opt_nowait" to the "FOR UPDATE" clause in the parser
> and checking for this option when trying to get the lock later?
My guess is that we will implement it was a SET variable so it can
control FOR UPDATE/LOCK/UPDATE/DELETE.
Added to TODO:
Add GUC variable to prevent waiting on locks
--
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 | Paulo Scardine | 2003-07-23 18:57:17 | Re: SELECT FOR UPDATE NOWAIT |
Previous Message | Kurt Roeckx | 2003-07-23 18:11:24 | Re: Fwd: Re: Possible psql bug |