From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Hans-Jürgen Schönig <postgres(at)cybertec(dot)at>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5 |
Date: | 2009-05-11 20:38:07 |
Message-ID: | 27182.1242074287@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I kinda agree with this. I believe Tom was arguing upthread that any
> change of this short should touch all of the places where NOWAIT is
> accepted now, and I agree with that. But having to issue SET as a
> separate statement and then maybe do another SET afterward to get the
> old value back doesn't seem like it provides any real advantage. GUCs
> are good for properties that you want to set and leave set, not so
> good for things that are associated with particular statements.
My point is that I don't believe the scenario where you say that you
know exactly how long each different statement in your application
should wait and they should all be different. What I do find credible
is that you want to set a "policy" for all the lock timeouts. Now
think about what happens when it's time to change the policy. A GUC
is gonna be a lot easier to manage than timeouts that are embedded in
all your individual queries.
> It also seems to me that there's no reason for NOWAIT to be part of
> the syntax, but WAIT n to be a GUC.
I wasn't happy about NOWAIT in the syntax, either ;-) ... but at least
that's a boolean and not a parameter whose specific value was plucked
out of thin air, which is what it's pretty much always going to be.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2009-05-11 21:47:37 | Re: Show method of index |
Previous Message | Boszormenyi Zoltan | 2009-05-11 20:37:18 | Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5 |