Re: 2PC support for pglogical

Поиск
Список
Период
Сортировка
От Stas Kelvich
Тема Re: 2PC support for pglogical
Дата
Msg-id C02A968F-E72B-4CA7-9475-ADBA43E3A554@postgrespro.ru
обсуждение исходный текст
Ответ на Re: 2PC support for pglogical  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: 2PC support for pglogical  (Craig Ringer <craig@2ndquadrant.com>)
Список pgsql-hackers
> On 24 Mar 2016, at 17:03, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Wed, Mar 23, 2016 at 1:44 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
>> On 10 March 2016 at 22:50, Stas Kelvich <s.kelvich@postgrespro.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




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Proposal: "Causal reads" mode for load balancing reads without stale data
Следующее
От: Robert Haas
Дата:
Сообщение: Re: RFC: replace pg_stat_activity.waiting with something more descriptive