Re: BUG #12808: BDR lock adding Postgis extension in one node - Mailing list pgsql-bugs

From 'Andres Freund'
Subject Re: BUG #12808: BDR lock adding Postgis extension in one node
Date
Msg-id 20150228093622.GA31643@awork2.anarazel.de
Whole thread Raw
In response to Re: BUG #12808: BDR lock adding Postgis extension in one node  ("Ruth Melendo" <rmelendo@teltronic.es>)
Responses Re: BUG #12808: BDR lock adding Postgis extension in one node  ("Ruth Melendo" <rmelendo@teltronic.es>)
List pgsql-bugs
Hi,

[some information has been acquired privately]

On 2015-02-27 15:30:20 +0100, Ruth Melendo wrote:
> The error got when adding a PostGIS extension from PGAdmin in node
> 1. Extension was created and the depending table too but in node 2 got
> the error when adding the extension because the depending table was
> not created.

> But, although the problem was originated for this, my main dude is how
> to fix the database then it=C2=B4s locked. What do I have to do? Becaus=
e
> now, I cannot do any DDL or DML against it.

The reason it's locked is that it's waiting for DDL to be
replicated. And that fails due to the spatial_ref_sys error.

In the version you're using the easiest way to resolve this is probably
to skip replication of the problematic transaction, and then fix up
things afterwards by hand.

To do that connect to the database you performed the CREATE EXTENSION
on. There get a list of the outgoing connections with a query like:

SELECT slot_name, datoid, database, active
FROM pg_replication_slots
WHERE slot_name LIKE 'bdr_'||(SELECT oid FROM pg_database WHERE datname =3D=
 current_database())||'_%';
=E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=
=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=
=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=
=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=
=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=
=80=E2=94=AC=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=
=E2=94=80=E2=94=AC=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=
=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=AC=E2=94=80=E2=94=80=E2=94=80=E2=94=
=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=90
=E2=94=82                slot_name                =E2=94=82 datoid =E2=94=
=82 database =E2=94=82 active =E2=94=82
=E2=94=9C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=
=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=
=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=
=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=
=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=
=80=E2=94=BC=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=
=E2=94=80=E2=94=BC=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=
=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=BC=E2=94=80=E2=94=80=E2=94=80=E2=94=
=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=A4
=E2=94=82 bdr_17911_6120567807158814813_1_16385__ =E2=94=82  17911 =E2=94=
=82 node_03  =E2=94=82 t      =E2=94=82
=E2=94=82 bdr_17911_6120567807158814813_1_17153__ =E2=94=82  17911 =E2=94=
=82 node_03  =E2=94=82 f      =E2=94=82
=E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=
=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=
=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=
=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=
=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=
=80=E2=94=B4=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=
=E2=94=80=E2=94=B4=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=
=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=B4=E2=94=80=E2=94=80=E2=94=80=E2=94=
=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=98
(2 rows)

In my three node setup those two consume changes from the node_03
database.

To consume the problematic transaction, use something like:

COPY (SELECT * FROM pg_logical_slot_get_binary_changes('bdr_17911_6120567=
807158814813_1_16385__', NULL, 1, 'interactive', 'true')) TO '/dev/null';

for each of the remote nodes. After that you should be able to execute
DDL again.

Then please reconnect and do
SET bdr.skip_ddl_replication =3D on;
DROP EXTENSION postgis;

That should bring the nodes back in sync with regard to the postgis
extension.


We'll work on making it possible to replicate extensions that insert
data into their own tables during creation.

Greetings,

Andres Freund

--=20
 Andres Freund                       http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

pgsql-bugs by date:

Previous
From: Michael Paquier
Date:
Subject: Re: BUG #12812: invalid attribute number for
Next
From: IPN Bala GSS TVL
Date:
Subject: Re: BUG #12812: invalid attribute number for