Re: [HACKERS] Issues with logical replication - Mailing list pgsql-hackers

From Stas Kelvich
Subject Re: [HACKERS] Issues with logical replication
Date
Msg-id DAA36A22-324E-46BA-9C39-2F135A08A956@postgrespro.ru
Whole thread Raw
In response to Re: [HACKERS] Issues with logical replication  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
Responses Re: [HACKERS] Issues with logical replication
List pgsql-hackers
> On 29 Nov 2017, at 18:46, Petr Jelinek <petr.jelinek@2ndquadrant.com> wrote:
>
> What I don't understand is how it leads to crash (and I could not
> reproduce it using the pgbench file attached in this thread either) and
> moreover how it leads to 0 xid being logged. The only explanation I can
> come up is that some kind of similar race has to be in
> LogStandbySnapshot() but we explicitly check for 0 xid value there.
>

Zero xid isn’t logged. Loop in XactLockTableWait() does following:

    for (;;)
    {
        Assert(TransactionIdIsValid(xid));
        Assert(!TransactionIdEquals(xid, GetTopTransactionIdIfAny()));

    <...>

        xid = SubTransGetParent(xid);
    }

So if last statement is reached for top transaction then next iteration
will crash in first assert. And it will be reached if whole this loop
happens before transaction acquired heavyweight lock.

Probability of that crash can be significantly increased be adding sleep
between xid generation and lock insertion in AssignTransactionId().




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



Attachment

pgsql-hackers by date:

Previous
From: Nikolay Shaplov
Date:
Subject: Re: [HACKERS] [PATCH] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind for custom AM
Next
From: Andrew Dunstan
Date:
Subject: Re: [HACKERS] SQL procedures