Re: BDR Alter table failing

So if I wanted to extend a column from 100 characters to 255 characters is
this permitted? The fact that I'm not making a change and the BDR kicked me
out makes me skeptical.

On Wed, Apr 27, 2016 at 11:56 AM, Craig Ringer <craig(at)2ndquadrant(dot)com>
wrote:

> On 27 April 2016 at 23:43, Alvaro Aguayo Garcia-Rada <
> aaguayo(at)opensysperu(dot)com> wrote:
>
>> Based on my experience, I can say BDR does not performs pre-DDL checks.
>> For example, if you try to CREATE TABLE with the name of an existing table,
>> BDR will acquire lock anyway, and then will fail when executing the DDL
>> statement on the first node, because the table already exists.
>>
>
> Correct, and it has to because otherwise it'd face a race condition where
> the table might be created between when it checked and when it tries to
> create it.
>
>> In your case, it's the same: BDR does not checks(nor needs to) if the DDL
>> statement is or not required, as that's a dba dutty. Then, BDR executes the
>> statement(ane acquires locks), and fails because it would require a full
>> table rewrite, which, at the time, is not supported by BDR.
>>
>
> Yeah. This is more of a "we never thought anyone would want to do that and
> didn't much care" problem. In this case we could lock the table and then
> inspect it. In fact we really should be locking it to prevent races, but we
> rely on the global DDL lock mechanism for that right now. (That's not what
> it's for, just a side-effect that's kind of handy).
>
> Applications *must* be adapted to run on BDR. You can't just point it at a
> BDR-enabled DB and go "we'll be right". DDL is one thing, but multimaster
> async replication conflicts are rather more significant concerns. Also
> handling of the currently somewhat quirky global sequence support's habit
> of ERRORing if you go too fast, trying to keep your transaction sizes down,
> and not trusting row locking for mutual exclusion between nodes. You can't
> use LISTEN/NOTIFY between nodes either, or advisory locking, or
> pg_largeobject ... yeah. Apps require audit and usually require changes.
> Changing an expected error code will be the least of your worries.
>
> --
> Craig Ringer http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services
>