Re: [BUGS] Re: BUG #14680: startup process on standby encounter adeadlock of TwoPhaseStateLock when redo 2PC xlog - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: [BUGS] Re: BUG #14680: startup process on standby encounter adeadlock of TwoPhaseStateLock when redo 2PC xlog
Date
Msg-id CAB7nPqQthLP9GvD2242epHKOBkDMd+03tSuFvK3cVZsGarQyWA@mail.gmail.com
Whole thread Raw
In response to [BUGS] Re: BUG #14680: startup process on standby encounter a deadlock ofTwoPhaseStateLock when redo 2PC xlog  (wangchuanting <wangchuanting@huawei.com>)
List pgsql-bugs
On Mon, Jun 5, 2017 at 8:32 PM, wangchuanting <wangchuanting@huawei.com> wrote:
> I don't understand why the patch remove TwoPhaseStateLock in MarkAsPrepared.

This one is on purpose, no low-level routines in this patch acquire
TwoPhaseStateLock. Logically I agree that it does not change much
but... You wrote something below about that.

> if so:
> 1. does it need remove lock acquire in MarkAsPreparing also?

No, MarkAsPreparing() is used only in the non-redo code path.

> 2. MarkAsPrepared will call ProcArrayAdd, and in ProcArrayAdd it acquires
> ProcArrayLock, we should carefully handle the lock sequence about these two
> locks.

And this gives a reason to not complicate our lives.
-- 
Michael

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Attachment

pgsql-bugs by date:

Previous
From: Andres Freund
Date:
Subject: Re: [BUGS] BUG #14687: pg_xlogdump does only count "main data" forrecord length and leading to incorrect statistics
Next
From: Mike Palmiotto
Date:
Subject: Re: [BUGS] BUG #14682: row level security not work with partitioned table