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 >
