Re: [BUGS] BUG #14680: startup process on standby encounter adeadlock of TwoPhaseStateLock when redo 2PC xlog
От | Michael Paquier |
---|---|
Тема | Re: [BUGS] BUG #14680: startup process on standby encounter adeadlock of TwoPhaseStateLock when redo 2PC xlog |
Дата | |
Msg-id | CAB7nPqQeOx96RC19STwR4eqgPX-5J8Vbow7n2_3ghfNtM3N+NQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [BUGS] BUG #14680: startup process on standby encounter a deadlock of TwoPhaseStateLock when redo 2PC xlog (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [BUGS] BUG #14680: startup process on standby encounter adeadlock of TwoPhaseStateLock when redo 2PC xlog
[BUGS] Re: BUG #14680: startup process on standby encounter a deadlock ofTwoPhaseStateLock when redo 2PC xlog |
Список | pgsql-bugs |
On Wed, May 31, 2017 at 6:57 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > wangchuanting@huawei.com writes: >> startup process on standby encounter a deadlock of TwoPhaseStateLock when >> redo 2PC xlog. > > Please provide an example of how to get into this state. That would help. Are you seeing in the logs something like "removing future two-phase state from memory for XXX" or "removing stale two-phase state from shared memory for XXX"? Even with that, the light-weight lock sequence taken in those code paths look definitely wrong to me, we should not take twice TwoPhaseStateLock in the same code path. I think that we should remove the lock acquisitions in RemoveGXact() and PrepareRedoRemove, and then upgrade the locks of PrescanPreparedTransactions() and StandbyRecoverPreparedTransactions() to be exclusive. We still need to keep a lock as CheckPointTwoPhase() may still be triggered by the checkpoint. Tom, what do you think? -- Michael -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
В списке pgsql-bugs по дате отправления: