On Tue, 2009-12-15 at 18:49 +0000, Simon Riggs wrote:
> This looks like the code is setting the parent to be zero.
[Sorry, that comment is completely off, misread the line number.]
The assertion is failing because the parent entry for that subxid had
already been set.
Investigating how that could come about, it looks like there is some
fairly strange stuff going on here. StandbyRecoverPreparedTransactions()
is never called at all.
The problem itself seems to be that xid assignment records cause us to
SubTransSetParent(), which is then repeated again during
RecoverPreparedTransactions(). So in Hot Standby mode it is possible
that we could mark the parent twice, just not in most cases.
So proposed fix is
* Include StandbyRecoverPreparedTransactions() somewhere in Hot Standby
startup, presumably after StartSubtrans().
* Skip assert when doing SubTransSetParent in
RecoverPreparedTransactions() when in Hot Standby mode because some
subxids will have been marked already
ISTM there is a further problem here: we log AccessExclusiveLocks for
all transactions, even ones that eventually get prepared. So we have
already separately logged the locks a prepared transaction will take.
All we need to do is reconstruct the subtrans entries. So
StandbyRecoverPreparedTransactions() can be edited down somewhat.
If you think this is correct, please say. If you know or suspect other
issues exist, let me know.
Just for reference, the issues relate to a number of distinct cases:
* xacts that prepare prior to starting point of HS
* xacts that remain prepared at end of recovery
* xacts that do both of the above things
We also need to cover the cases where we have prepared xacts with
AccessExclusiveLocks and/or subxacts (subcase of >64 subxids).
AFAICS we have 2 bugs already and a enough complexity to make me believe
there are more lurking. I'm about ready to disable Hot Standby
completely when max_prepared_transactions > 0, at least for Alpha3 and
possibly for 8.5 altogether.
Comments?
-- Simon Riggs www.2ndQuadrant.com