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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
