On Thu, Oct 2, 2014 at 1:52 PM, Claudio Freire <klaussfre...@gmail.com> wrote: > 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).
I think that there are very few problems with recognizing when an AccessExclusiveLock is needed or not needed. The exceptions to the rule that DDL needs such a lock are narrow enough that I have a hard time believing that most people think about it, or even need to think about it. I wish that wasn't the case, but it is. > 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. I think the problem you'll have with NOWAIT is: you have an error from having to wait...what now? Do you restart? I imagine this would frequently result in what is effectively lock starvation. Any old AccessShareLock-er is going to make our migration tool restart. We'll never finish. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
