From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: 2PC support for pglogical |
Date: | 2016-03-25 12:53:38 |
Message-ID: | CAMsr+YHAtXwN7FUH6qiE_D9zgwR4wSg84xkkrBWeKjLSDsnMZg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 24 March 2016 at 22:20, Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru> wrote:
>
> I think all the locking already handled properly by creating dummy backend
> in PGPROC, as it done in usual postgres 2pc implementation.
>
>
On the downstream, yes. But what about the decoding, reorder buffer and
output plugin? They access the relcache etc. If you changed the structure
of a table in a prepared xact you have to make sure you get that right.
> Just checked DDL with following scenario:
>
> * prepare tx that inserts a row in table on master
> * execute DROP TABLE on pglogical slave
> * commit prepared on master
>
> Now it behaves as expected — slave blocks DROP TABLE until commit prepared
> on master.
>
Try doing DDL in the prepared xact on the upstream side, especially things
that make structural changes to tables. Test both things that do full-table
rewrites (alter table ... add column ... default not null) and things that
don't (alter table ... drop column ; alter table ... add column ...;
without not null or default).
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-03-25 12:55:46 | Re: VS 2015 support in src/tools/msvc |
Previous Message | Craig Ringer | 2016-03-25 12:48:56 | Re: NOT EXIST for PREPARE |