From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@postgreSQL.org
Subject: StandbyRecoverPreparedTransactions recovers subtrans links incorrectly
Date: Sat, 22 Apr 2017 19:55:18 -0400
Message-ID: <20110.1492905318@sss.pgh.pa.us> (raw)
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Now that we've got consistent failure reports about the 009_twophase.pl
recovery test, I set out to find out why it's failing. It looks to me
like the reason is that this (twophase.c:2145):
SubTransSetParent(xid, subxid, overwriteOK);
ought to be this:
SubTransSetParent(subxid, xid, overwriteOK);
because the definition of SubTransSetParent is
void
SubTransSetParent(TransactionId xid, TransactionId parent, bool overwriteOK)
not the other way 'round.
While "git blame" blames this line on the recent commit 728bd991c,
that just moved the call from somewhere else. AFAICS this has actually
been wrong since StandbyRecoverPreparedTransactions was written,
in 361bd1662 of 2010-04-13.
It's not clear to me how much potential this has to create user data
corruption, but it doesn't look good at first glance. Discuss.
Also, when I fix that, it gets further but still crashes at the same
Assert in SubTransSetParent. The proximate cause this time seems to be
that RecoverPreparedTransactions's calculation of overwriteOK is wrong:
it's computing that as "false", but in reality the subtrans link in
question has already been set.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us
Subject: Re: StandbyRecoverPreparedTransactions recovers subtrans links incorrectly
In-Reply-To: <20110.1492905318@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox