Date: Wed, 14 Jun 2017 11:35:10 -0400
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: wangchuanting <wangchuanting@huawei.com>,
	PostgreSQL mailing lists <pgsql-bugs@postgresql.org>
Subject: Re: Re: BUG #14680: startup process on standby encounter a
 deadlock of TwoPhaseStateLock when redo 2PC xlog
Message-ID: <20170614153510.l57n2dgr3ukkgla4@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAB7nPqQnfR5aHr+Qtr2RJiw59yOkcQSrhTto2ZfDqFVn+iGmtw@mail.gmail.com>
User-Agent: NeoMutt/20170306-137-4415bd-dirty (1.8.0)
Precedence: bulk
Sender: pgsql-bugs-owner@postgresql.org

Michael Paquier wrote:
> On Wed, Jun 14, 2017 at 8:08 AM, Alvaro Herrera
> <alvherre@2ndquadrant.com> wrote:
> > So I propose that RecoverPreparedTransactions grabs exclusive lock at
> > the top, and only the bottom part of the loop is done unlocked, which
> > AFAICS should be safe.  (MarkAsPrepared gained a boolean argument
> > indicating that caller already holds lock).
> 
> Logically both approaches are really close as with this approach the
> additional locked area is when scanning the entries of TwoPhaseState.
> But I agree that your suggestion would be safer in the long run. This
> looks good to me after a close look.

Thanks, pushed.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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