Re: [BUGS] Re: BUG #14680: startup process on standby encounter adeadlock of TwoPhaseStateLock when redo 2PC xlog
От | Michael Paquier |
---|---|
Тема | Re: [BUGS] Re: BUG #14680: startup process on standby encounter adeadlock of TwoPhaseStateLock when redo 2PC xlog |
Дата | |
Msg-id | CAB7nPqSZwUbHX6jejbVbeB1LfrKHFf5giuTLjFXTXXtq8LZcxQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [BUGS] Re: BUG #14680: startup process on standby encounter adeadlock of TwoPhaseStateLock when redo 2PC xlog (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: [BUGS] Re: BUG #14680: startup process on standby encounter adeadlock of TwoPhaseStateLock when redo 2PC xlog
|
Список | pgsql-bugs |
On Tue, Jun 13, 2017 at 7:49 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > However, I found out that this rationale is likely not true, because the > checkpointer may be running concurrently with this code from startup > process, and checkpointer does process 2PC data. Maybe there are other > reasons why there's no live bug here, but it looks wrong (I didn't try > to reproduce a problem). The current coding is actually safe because the checkpointer does not remove or add any 2PC entry in the array while holding TwoPhaseStateLock, it just updates some values that need to be read and/or written while holding the lock. Well, to be honest, HEAD is wrong because it can read a flag value while the checkpointer updates it, and the patch is careful to change that to be correct. The wrong part is when calling ProcessTwoPhaseBuffer() in RecoverPreparedTransactions() which accesses gxact->ondisk and prepare_start_lsn without locking things. -- 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 по дате отправления: