Re: BDR Alter table failing - Mailing list pgsql-general
| From | Alvaro Aguayo Garcia-Rada |
|---|---|
| Subject | Re: BDR Alter table failing |
| Date | |
| Msg-id | buec6a7sm0r1r1uphsnuckf4.1461783487158@email.android.com Whole thread Raw |
| In response to | Re: BDR Alter table failing (Will McCormick <wmccormick@gmail.com>) |
| List | pgsql-general |
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 ----
On 27 April 2016 at 23:43, Alvaro Aguayo Garcia-Rada <aaguayo@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.--
pgsql-general by date: