From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Boszormenyi Zoltan <zb(at)cybertec(dot)at> |
Cc: | Hans-Juergen Schoenig <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 18:01:34 |
Message-ID: | 7068.1242064894@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Boszormenyi Zoltan <zb(at)cybertec(dot)at> writes:
> Tom Lane rta:
>> I think the way you're describing would be both harder to implement
>> and full of its own strange traps.
> Why?
Well, for one thing: if I roll back a subtransaction, should the lock
wait time it used now no longer count against the total? If not,
once a timeout failure has occurred it'll no longer be possible for
the total transaction to do anything, even if it rolls back a failed
subtransaction.
But more generally, what you are proposing seems largely duplicative
with statement_timeout. The only reason I can see for a
lock-wait-specific timeout is that you have a need to control the
length of a specific wait and *not* the overall time spent. Hans
already argued upthread why he wants a feature that doesn't act like
statement_timeout.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-05-11 18:04:22 | Re: BUG #4721: All sub-tables incorrectly included in search plan for partitioned table |
Previous Message | Boszormenyi Zoltan | 2009-05-11 17:56:00 | Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5 |