Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5

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

In response to

Responses

Browse pgsql-hackers by date

  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