Re: BDR: ALTER statement hanging - Mailing list pgsql-general

Thanks, I removed the other nodes from bdr.bdr_nodes table, deleted all the bdr_connections and
pg_replication_identifierentries, dropped the pg_replication_slots restarted the instance and then trying the ALTER
statementresulted in: 

ERROR:  No peer nodes or peer node count unknown, cannot acquire DDL lock
HINT:  BDR is probably still starting up, wait a while

The only way I could issue the statement is run the following to convert the node to a standalone instance:

BEGIN;
SET LOCAL bdr.permit_unsafe_ddl_commands = true;
SET LOCAL bdr.skip_ddl_locking = true;
security label for 'bdr' on database deliver is '{"bdr": false}';
COMMIT;

I am still puzzled as to why the bdr_nodes node_status was reporting "i" when there were no errors in the logs.

-Selim

________________________________________
From: pgsql-general-owner@postgresql.org [pgsql-general-owner@postgresql.org] on behalf of Andreas Kretschmer
[andreas@a-kretschmer.de]
Sent: Friday, December 04, 2015 9:59 AM
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] BDR: ALTER statement hanging

> Selim Tuvi <stuvi@ilm.com> hat am 4. Dezember 2015 um 18:46 geschrieben:
>
>
> Yes they seem to be active:
>
> deliver=# select * from pg_replication_slots;
>                 slot_name                 | plugin | slot_type | datoid |
> database | active | xmin | catalog_xmin | restart_lsn
>
------------------------------------------+--------+-----------+--------+----------+--------+------+--------------+-------------
>  bdr_533136_6223770712502831127_1_16389__ | bdr    | logical   | 533136 |
> deliver  | t      |      |       182302 | 0/9C8A5598
>  bdr_533136_6223800735012265413_1_16389__ | bdr    | logical   | 533136 |
> deliver  | t      |      |       182302 | 0/9C8A5598
> (2 rows)
>
> Although when I look at bdr.bdr_nodes I see the status as still initializing
> for the other two nodes, I don't know if that could cause this problem:
>
> deliver=# select * from bdr.bdr_nodes;
>      node_sysid      | node_timeline | node_dboid | node_status |
>              node_name              |
>                                             node_local_dsn
>                                          |
>                                          node_init_from_dsn
>
---------------------+---------------+------------+-------------+-------------------------------------+---------------------------------------------------------------
>
-----------------------------------------+------------------------------------------------------------------------------------------------------
>  6212648563684174798 |             1 |     533136 | r           |
> pe-deliverdb-sf-01v | host=pe-deliverdb-sf-01v port=5432 dbname=deliver
> user=deliver_admin password=xxxxx   |
>  6223770712502831127 |             1 |      16389 | i           |
> pe-deliverdb-sing-01v | host=pe-deliverdb-sing-01v port=5432 dbname=deliver
> user=deliver_admin password=xxxxx | host=pe-deliverdb-sf-01v port=5432
> dbname=deliver user=deliver_admin password=xxxxx
>  6223800735012265413 |             1 |      16389 | i           |
> pe-deliverdb-lon-01v | host=pe-deliverdb-lon-01v port=5432 dbname=deliver
> user=deliver_admin password=xxxxx  | host=pe-deliverdb-sf-01v port=5432
> dbname=deliver user=deliver_admin password=xxxxx
>
> -Selim
>


I think, the state 'i' is the main reason for your problem, because of: "i-
Joining: The node is doing initial slot creation or an initial dump and load".

But i can't tell you why this nodes are in this state.


Regards, Andreas


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general