| From: | Peter Geoghegan <pg(at)heroku(dot)com> |
|---|---|
| To: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
| Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: DDL Damage Assessment |
| Date: | 2014-10-02 21:00:06 |
| Message-ID: | CAM3SWZSHJtWg5k2d7bgbOeys0D-EmO6hErDTd+okSvqFo05jvw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Oct 2, 2014 at 1:52 PM, Claudio Freire <klaussfreire(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2014-10-02 21:03:59 | Re: DDL Damage Assessment |
| Previous Message | Claudio Freire | 2014-10-02 20:52:29 | Re: DDL Damage Assessment |