Re: [HACKERS] Issues with logical replication
Stas Kelvich <s.kelvich@postgrespro.ru>
From: Stas Kelvich <s.kelvich@postgrespro.ru>
To: Petr Jelinek <petr.jelinek@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>,
Andres Freund <andres@anarazel.de>,
Konstantin Knizhnik <k.knizhnik@postgrespro.ru>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Date: 2017-11-29T19:11:25Z
Lists: pgsql-hackers
Attachments
- AssignTransactionId.patch (application/octet-stream) patch
- (unnamed) (text/plain)
> 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().
Commits
-
Make XactLockTableWait work for transactions that are not yet self-locked
- fe0cc5ba5372 9.6.7 landed
- d8d5354bba43 9.5.11 landed
- 43fb4b42230d 10.2 landed
- 3c27944fb214 11.0 landed
- fe6bdc0a38c7 9.4.16 landed