Обсуждение: BDR - DDL Locking

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.

Will,

I saw after replying that there's more detail I missed in your mail,
so please see the more detailed reply inline below.

On 20 October 2015 at 23:31, Will McCormick <wmccormick@gmail.com> wrote:
> First time user here and new to PostgreSQL and BDR so I hope I have the
> right place.

You do.

> I attempted to issues a TRUNCATE TABLE without the cascade option on a
> Parent table that had a child FK constraint.

I've looked at your logs, and it looks like the TRUNCATE suceeded on
the node that was doing the DDL and it was queued for replication.
Then, when applying to another node, it failed because there was a
foreign key relationship referencing the target table.

This is odd, because the way BDR captures TRUNCATEs should prevent
that from happening. It uses triggers to capture TRUNCATES and
enqueues them for execution. However, I can see upon inspection that
the approach used just isn't sufficient to handle FK relationships,
and that the current test suite doesn't cover this.

I'm going to write a test to confirm what I think is going on, then follow up.


--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services