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

Tom Lane wrote:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
>
>> Jeff,
>>
>>> Will statement_timeout not suffice for that use case?
>>>
>
>
>> Well, currently statement_timeout doesn't affect waiting for locks.
>>
>
> Sure it does.
>
>
>> And as a DBA, I don't think I'd want the same timeout for executing
>> queries as for waiting for a lock.
>>

this is exactly the point it is simply an additional use case.
while statement_timeout is perfect to kick out queries which take too
long a lock_timeout serves a totally different purpose because you will
get a totally different error message. imagine some old 4GL terminal
application: in this case you will hardly reach a statement_timeout
because you will simply want to wait until things appear on your screen.
however, you definitely don't want to wait forever if somebody keeps
working on some product which is on stock and never finishes.

btw, this old terminal application i was talking about is exactly the
usecase we had - this is why this patch has been made.
we are porting roughly 2500 terminal application from informix to
postgresql. we are talking about entire factory production lines and so
on here (the ECPG patches posted recently are for the same project, btw.).
there are countless use-cases where you want to know whether you are
locked out or whether you are just taking too long - the message is
totally different. the goal of the patch is to have a mechanism to make
sure that you don't starve to death.

as far is syntax is concerned: there are good reasons for WAIT and good
reasons for a GUC.
while the WAIT syntax is clearly for a very precise instruction for a
very certain place in a program, a GUC is a more overall policy. i don't
see a reason why we should not have both anyway.
a GUC has the charm that it can be assigned to roles, procedures, etc.
nicely a WAIT clause has the charm of being incredibly precise. i can
see good arguments for both.
the code itself is pretty simplistic - it needs no effort to be up to
date and it does not harm anything else - it is pretty isolated.

many thanks,

hans

--
Cybertec Schoenig & Schoenig GmbH
Reyergasse 9 / 2
A-2700 Wiener Neustadt
Web: www.postgresql-support.de