Hans-Juergen Schoenig <postgres@cybertec.at> writes:
> i would like to propose an extension to our SELECT FOR UPDATE mechanism.
> especially in web applications it can be extremely useful to have the
> chance to terminate a lock after a given timeframe.
I guess my immediate reactions to this are:
1. Why SELECT FOR UPDATE in particular, and not other sorts of locks?
2. That "clear and easy to use" oracle syntax sucks. You do not want
to be embedding lock timeout constants in your application queries.
When you move to a new server and the appropriate timeout changes,
do you want to be trying to update your clients for that?
What I think has been proposed previously is a GUC variable named
something like "lock_timeout", which would cause a wait for *any*
heavyweight lock to abort after such-and-such an interval. This
would address your point about not wanting to use an overall
statement_timeout, and it would be more general than a feature
that only works for SELECT FOR UPDATE row locks, and it would allow
decoupling the exact length of the timeout from application query
logic.
regards, tom lane
