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