On 10 October 2015 at 02:53, Selim Tuvi <stuvi@xxxxxxx> wrote: > node: deliver_sing (the problem node): > > postgres=# SELECT * FROM pg_catalog.pg_replication_identifier; > riident | riname > ---------+---------------------------------------- > 1 | bdr_6197393155020108291_1_47458_16385_ > 2 | bdr_6199712740068695651_1_16385_16385_ > 3 | bdr_6197393155020108291_1_47458_17167_ > 4 | bdr_6199712740068695651_1_16385_17167_ > 5 | bdr_6199712740068695651_1_18817_17951_ > 6 | bdr_6197393155020108291_1_48609_17951_ > 7 | bdr_6197393155020108291_1_48609_19685_ > 8 | bdr_6199712740068695651_1_18817_19685_ > (8 rows) > On 9 October 2015 at 06:54, Selim Tuvi <stuvi@xxxxxxx> wrote: >> "recovered replication state of node 6 to 0/59F35A8",,,,,,,,,"" >> "no free replication state could be found, increase >> max_replication_slots",,,,,,,,,"" The number of supported replication identifiers (in bdr 9.4) is controlled by max_replication_slots, hence the error message. This should be documented; I'll amend the docs appropriately. https://github.com/2ndQuadrant/bdr/issues/133 The identifiers aren't currently dropped during node part, which should be changed. It hasn't come up to date because frequent node addition and removal is something to be avoided, and because most deployments configure room for more slots than needed to avoid future restarts. https://github.com/2ndQuadrant/bdr/issues/134 -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
