On Thu, Oct 2, 2014 at 5:37 PM, Peter Geoghegan <p...@heroku.com> wrote: > Session 3 is an innocent bystander. It goes to query the same table in > an ordinary, routine way - a SELECT statement. Even though session 2's > lock is not granted yet, session 3 is not at liberty to skip the queue > and get its own AccessShareLock. The effect is about the same as if > session 2 did need to hold an AccessExclusiveLock for ages: read > queries block for a long time. And yet, in theory session 2's impact > on production should not be minimal, if we consider something like > EXPLAIN output.
The explain would show the AccessExclusiveLock, so it would be enough for a heads-up to kill all idle-in-transaction holding locks on the target relation (if killable, or just wait). Granted, it's something that's not easily automatable, whereas a nowait is. However, rather than nowait, I'd prefer "cancellable" semantics, that would cancel voluntarily if any other transaction requests a conflicting lock, like autovacuum does. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers