Re: logical replication busy-waiting on a lock

From: Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Subject: Re: logical replication busy-waiting on a lock
Date: 2017-05-29 21:49:33
Message-ID: 9c983a2e-2fd6-1572-d434-f36018fec143@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 29/05/17 21:44, Andres Freund wrote:
>
>
> On May 29, 2017 12:41:26 PM PDT, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com> wrote:
>> On 29/05/17 21:28, Andres Freund wrote:
>>>
>>> On May 29, 2017 12:25:35 PM PDT, Petr Jelinek
>> <petr(dot)jelinek(at)2ndquadrant(dot)com> wrote:
>>>>
>>>> Looking at the code more, the xid is only used as parameter for
>>>> SnapBuildBuildSnapshot() which never does anything with that
>> parameter,
>>>> I wonder if it's really needed then.
>>>
>>> Not at a computer, but by memory that'll trigger the snapshot export
>> routine to include it. Import in turn requires the xid to check if the
>> source is still alive. But there's better ways, e.g. using the virtual
>> xactid.
>>>
>>
>> It does, and while that's unfortunate the logical replication does not
>> actually export the snapshots. It uses the USE_SNAPSHOT option where
>> the
>> snapshot is just installed into current transaction but not exported.
>> So
>> not calling the GetTopTransactionId() would solve it at least for that
>> in-core use-case. I don't see any bad side effects from doing so yet,
>> so
>> it might be good enough solution for PG10.
>
> In the general case you can't do so, because of vacuum and such. Even for LR we need to make sure the exporting session didn't die badly, deleting the slot. Hence suggestion to use the virtual xid.
>

I am not quite sure I understand (both the vxid suggestion and for the
session dying badly). Maybe we can discuss bit more when you get to
computer so it's easier for you to expand on what you mean.

--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Rofail 2017-05-29 23:18:40 Re: GSoC 2017: Foreign Key Arrays
Previous Message Alvaro Herrera 2017-05-29 21:40:21 Re: [PATCH] Fixed malformed error message on malformed SCRAM message.