From: | Will McCormick <wmccormick(at)gmail(dot)com> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: BDR - DDL Locking |
Date: | 2015-10-21 13:37:43 |
Message-ID: | CA+jgkY5E_if1cEZ837k2SU777MMRYhF+Ctb5TjuYVg+UCt2JCw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hey Craig thank you very much for your response.
> When you say you "attempted to" - what was the outcome?
I tried a truncate without the cascade option. After that I tried it with
the cascade option. The session just hanged indefinitely at that point.
There was no rollback and I was testing on an empty table.
Replication was in a ready state on both nodes and both DDL and DML was
replicating.
0.9.2.0 BDR
When you say restarting the nodes. I did restart postgres and this didn't
help.
On Wed, Oct 21, 2015 at 8:31 AM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> What's the *exact* BDR version?
>
> When you say you "attempted to" - what was the outcome? Presumably an
> ERROR from the TRUNCATE, right? That would roll back the transaction,
> and in the process abort the DDL lock acquisition attempt.
>
> Are you sure replication was working normally prior to this point,
> with no issues?
>
> The global DDL lock isn't a true lock in the sense that it appears in
> pg_locks, etc. If you roll back the transaction trying to acquire it,
> or terminate the PostgreSQL backend attempting to acquire it - such as
> your TRUNCATE - using pg_terminate_backend(...) then it will be
> removed automatically. If for any reason that is not the case (which
> it shouldn't be) then restarting the nodes will clear it.
>
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2015-10-21 13:38:37 | Re: BDR - DDL Locking |
Previous Message | Adrian Klaver | 2015-10-21 13:08:56 | Re: trouble downloading postgres 9.4 for RHEL 6.x |