Re: DDL Damage Assessment
От | Peter Geoghegan |
---|---|
Тема | Re: DDL Damage Assessment |
Дата | |
Msg-id | CAM3SWZSHJtWg5k2d7bgbOeys0D-EmO6hErDTd+okSvqFo05jvw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: DDL Damage Assessment (Claudio Freire <klaussfreire@gmail.com>) |
Список | pgsql-hackers |
On Thu, Oct 2, 2014 at 1:52 PM, Claudio Freire <klaussfreire@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
В списке pgsql-hackers по дате отправления: