Re: Hot Standby and prepared transactions

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Hiroyuki Yamada <yamada(at)kokolink(dot)net>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Hot Standby and prepared transactions
Date: 2009-12-17 11:36:21
Message-ID: 1261049781.634.2885.camel@ebony
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2009-12-17 12:02:29 Re: Streaming replication and non-blocking I/O
Previous Message Heikki Linnakangas 2009-12-17 11:24:52 Re: Hot Standby and prepared transactions