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 19:27:47
Message-ID: f6b804a3-9891-b30b-e8b6-d61052b0af9e@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 29/05/17 21:23, Andres Freund wrote:
>
>
> On May 29, 2017 12:21:50 PM PDT, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com> wrote:
>> On 29/05/17 20:59, Andres Freund wrote:
>>>
>>>
>>> On May 29, 2017 11:58:05 AM PDT, Petr Jelinek
>> <petr(dot)jelinek(at)2ndquadrant(dot)com> wrote:
>>>> On 27/05/17 17:17, Andres Freund wrote:
>>>>>
>>>>>
>>>>> On May 27, 2017 9:48:22 AM EDT, Petr Jelinek
>>>> <petr(dot)jelinek(at)2ndquadrant(dot)com> wrote:
>>>>>> Actually, I guess it's the pid 47457 (COPY process) who is
>> actually
>>>>>> running the xid 73322726. In that case that's the same thing
>>>> Masahiko
>>>>>> Sawada reported [1]. Which basically is result of snapshot builder
>>>>>> waiting for transaction to finish, that's normal if there is a
>> long
>>>>>> transaction running when the snapshot is being created (and the
>> COPY
>>>> is
>>>>>> a long transaction).
>>>>>
>>>>> Hm. I suspect the issue is that the exported snapshot needs an xid
>>>> for some crosscheck, and that's what we're waiting for. Could you
>>>> check what happens if you don't assign one and just content the
>> error
>>>> checks out? Not at my computer, just theorizing.
>>>>>
>>>>
>>>> I don't think that's it, in my opinion it's the parallelization of
>>>> table
>>>> data copy where we create snapshot for one process but then the next
>>>> one
>>>> has to wait for the first one to finish. Before we fixed the
>>>> snapshotting, the second one would just use the ondisk snapshot so
>> it
>>>> would work fine (except the snapshot was corrupted of course). I
>> wonder
>>>> if we could somehow give it a hint to ignore the read-only txes, but
>>>> then we have no way to enforce the txes to stay read-only so it does
>>>> not
>>>> seem safe.
>>>
>>> Read-only txs have no xid ...
>>>
>>
>> That's what I mean by hinting, normally they don't but building initial
>> snapshot in snapshot builder calls GetTopTransactionId() (see
>> SnapBuildInitialSnapshot()) which will assign it xid.
>
> That's precisely what I pointed out a few emails above, and what I suggest changing.
>

Ah didn't realize that's what you meant. I can try playing with it.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2017-05-29 19:28:24 Re: logical replication busy-waiting on a lock
Previous Message Sven R. Kunze 2017-05-29 19:26:47 Re: Surjective functional indexes