Re: [HACKERS] logical replication busy-waiting on a lock - Mailing list pgsql-hackers

From Petr Jelinek
Subject Re: [HACKERS] logical replication busy-waiting on a lock
Date
Msg-id 9c983a2e-2fd6-1572-d434-f36018fec143@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] logical replication busy-waiting on a lock  (Andres Freund <andres@anarazel.de>)
Responses Re: [HACKERS] logical replication busy-waiting on a lock  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 29/05/17 21:44, Andres Freund wrote:
> 
> 
> On May 29, 2017 12:41:26 PM PDT, Petr Jelinek <petr.jelinek@2ndquadrant.com> wrote:
>> On 29/05/17 21:28, Andres Freund wrote:
>>>
>>> On May 29, 2017 12:25:35 PM PDT, Petr Jelinek
>> <petr.jelinek@2ndquadrant.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
sessiondidn'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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] pg_resetwal is broken if run from v10 against older version of PG data directory
Next
From: Mark Rofail
Date:
Subject: Re: [HACKERS] GSoC 2017: Foreign Key Arrays