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 <cr...@2ndquadrant.com> wrote: > On 27 April 2016 at 23:43, Alvaro Aguayo Garcia-Rada < > aagu...@opensysperu.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 >
