Re: 2PC support for pglogical

From: Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Craig Ringer <craig(at)2ndquadrant(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 2PC support for pglogical
Date: 2016-03-24 14:20:14
Message-ID: C02A968F-E72B-4CA7-9475-ADBA43E3A554@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> On 24 Mar 2016, at 17:03, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Wed, Mar 23, 2016 at 1:44 AM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
>> On 10 March 2016 at 22:50, Stas Kelvich <s(dot)kelvich(at)postgrespro(dot)ru> wrote:
>>> Hi.
>>>
>>> Here is proof-of-concept version of two phase commit support for logical
>>> replication.
>>
>> I missed this when you posted it, so sorry for the late response.
>>
>> I've read through this but not tested it yet. I really appreciate you doing
>> it, it's been on my wishlist/backburner for ages.
>>
>> On reading through the patch I noticed that there doesn't seem to be any
>> consideration of locking. The prepared xact can still hold strong locks on
>> catalogs. How's that handled? I think Robert's group locking stuff is what
>> we'll want here - for a prepared xact we can join the prepared xact as a
>> group lock member so we inherit its locks. Right now if you try DDL in a
>> prepared xact I suspect it'll break.
>
> I have grave doubts about that approach. It's not impossible it could
> be right, but I wouldn't bet the farm on it.
>

I think all the locking already handled properly by creating dummy backend in PGPROC, as it done in usual postgres 2pc implementation.

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.

---
Stas Kelvich
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-03-24 14:23:41 Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Previous Message Robert Haas 2016-03-24 14:20:13 Re: Proposal: "Causal reads" mode for load balancing reads without stale data