| 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: | Whole Thread | Raw Message | 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 |