On Thu, 2009-12-17 at 19:55 +0900, Hiroyuki Yamada wrote:
> Well, I've read some more and have a question.
>
> The implementation assumes that transactions write COMMIT/ABORT WAL at the end
> of them, while it does not seem to write ABORT WAL in immediate shutdown. So,
>
> 1. acquire ACCESS EXCLUSIVE lock in table A in xact 1
> 2. execute immediate shutdown of the active node
> 3. restart it
> 4. acquire ACCESS EXCLUSIVE lock in table A in xact 2
>
> ...then, duplicate lock acquisition by two diffrent transactions can occur in the standby node.
>
> Am I missing something ? Or is this already reported ?
This was a tricky point in the design because we already knew that abort
records are not always written for every transaction.
ProcArrayApplyRecoveryInfo() was specifically designed to prune away
older transactions that might have become stuck in that state, which
calls StandbyReleaseOldLocks() to remove any such locks. The pruning
operation is also one of the reasons why we need to log
XLOG_RUNNING_XACTS on a regular basis.
Duplicate lock acquisition isn't specifically checked for, since it is
blocked on primary, but lock release if duplicates did exist is handled.
I've checked the code some more to see if the above is possible. At step
(3) we perform a shutdown checkpoint, which would/should be responsible
for performing the prune operation that would prevent your case from
being a problem.
The code around shutdown checkpoint has changed a few times and it looks
like that bug has been introduced by my edit on Dec 6 to prevent
shutdown checkpoint as starting places. They need to be handled, since
we now don't write a XLOG_RUNNING_XACTS record during a shutdown
checkpoint.
I will re-add this now.
Thanks again: keep going, you're on a roll.
-- Simon Riggs www.2ndQuadrant.com