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

Tom,

> My point is that I don't believe the scenario where you say that you
> know exactly how long each different statement in your application
> should wait and they should all be different. What I do find credible
> is that you want to set a "policy" for all the lock timeouts. Now
> think about what happens when it's time to change the policy. A GUC
> is gonna be a lot easier to manage than timeouts that are embedded in
> all your individual queries.

For production applications, it's credible that you're going to desire
three different behaviors for different locks: you'll want to not wait
at all for some locks, wait a limited time for others, and for a few
wait forever. I agree that the time for the 2nd case wouldn't vary per
lock in any reasonable case.

I can see Zoltan's argument: for web applications, it's important to
keep the *total* wait time under 50 seconds for most users (default
browser timeout for most is 60 seconds). So it would certainly be nice
if we could somehow set total wait time instead of individual operation
wait time. It's also completely and totally unworkable on the database
layer for multiple reasons, so I'm not going to bother pushing any idea
which implements this.

So, I can see having a session-based lock_timeout GUC, and also a NOWAIT
statement. It would mean that users would need to set lock_timeout=-1
if they didn't want the lock to timeout, but that's consistent with how
other timeouts behave.

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