Re: Hot Standby and prepared transactions
От | Simon Riggs |
---|---|
Тема | Re: Hot Standby and prepared transactions |
Дата | |
Msg-id | 1261049781.634.2885.camel@ebony обсуждение исходный текст |
Ответ на | Re: Hot Standby and prepared transactions (Hiroyuki Yamada <yamada@kokolink.net>) |
Список | 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
В списке pgsql-hackers по дате отправления: