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

Tom,

> Well, that's exactly what Jeff is questioning. How big is the use-case
> for that exactly?

I think that it's not necessary to have a 2nd GUC, but for a different
reason than argued.

For the applications I work on, I tend to set statement_timeout to
something high designed just to catch runaway queries, like 2min or 5min
(or 1 hour on data warehouses). Partly this is because
statement_timeout is so indiscriminate, and I don't want to terminate
queries I actually wanted to complete. If the lock time is included in
the statement_timeout counter, even more so.

This would mean that I'd want a lock_timeout which was much shorter than
the statement_timeout. However, I also stand by my statement that I
don't think that a blanket per-server lock_timeout is that useful; you
want the lock timeout to be based on how many locks you're waiting for,
what the particular operation is, what the user is expecting, etc. And
you need so send them a custom error message which explains the lock wait.

So, while some people have asserted that a lock_timeout GUC would allow
users to retrofit older applications to time out on locks, I just don't
see that being the case. You'd have to refactor regardless, and if
you're going to, just add the WAIT statement to the lock request.

So, -1 from me on having a lock_timeout GUC for now.

However, I think this is another one worth taking an informal blog poll
to reach users other than hackers, yes?

--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com