On 10 October 2015 at 02:53, Selim Tuvi <stuvi@ilm.com> 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@ilm.com> 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
