Re: BDR Alter table failing

If you change the length of a character varying, it should work. I'm almost sure I have done that before on my BDR cluster.

It may work as long as it does not require a full table rewrite. I think, the length change for a character varying won't need a full table rewrite, as the length is only a limit, but the actual content is length-independent.

Also, even if it works for character varying, it may not work for other types, specially numeric types.

Regards,

Alvaro Aguayo
Jefe de Operaciones
Open Comb Systems E.I.R.L.

Oficina: (+51-1) 3377813 | RPM: #034252 / (+51) 995540103  | RPC: (+51) 954183248
Website: www.ocs.pe

Sent from my Sony Xperia™ smartphone

---- Will McCormick wrote ----

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
>