On 16 June 2015 at 18:40, Sylvain MARECHAL <marechal.sylvain2@gmail.com> wrote:
> Nothing special in the logs here. What I would like to emphasize is that a
> single node can not live alone.
Yes, that's right.
"Single node BDR", i.e. running with BDR enabled but no peers, would
be nice to support for testing and robustness. It's just not a key
priority at this point.
>>> -- Now detach the group, in the hope to create some table
>>> -- But this does not work. DDL are still forbidden
>>> test=# select bdr.bdr_part_by_node_names('{node1}');
>>
>> You shouldn't part a node from its self. The next revision will
>> prevent this with an error.
>
>
> Ok, this was not clear for me.
Or anyone else, hence the coming docs and code changes.
> Ok, I will do this as a workaround.
> But having a function doing the detach() properly would be really nice.
We have a very long list of "would be nice"s, but have to focus on
things that are core requirements for functionality or for specific
customer needs. At this point this comes under neither category, so I
don't anticipate working on it soon. If you're interested in getting
into the codebase it would be an interesting and manageable project,
though...
> Of course, in a real production scenario, the user won't probably change
> often its configuration, but I think this is really useful to have this kind
> of flexibility when taking control of the application.
Absolutely. The trouble is that all such things have trade-offs.
For example, with the ability to re-attach a node that you asked
about, doing so can't be done without accumulating lots of upstream
WAL. It'd be effectively identical to just shutting down the node then
starting it up again - with all the same costs and downsides.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services