pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: wangchuanting <wangchuanting@huawei.com>
Cc: 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
Date: Sat, 10 Jun 2017 23:24:48 -0400
Message-ID: <20170611032448.f2da5epz5pnbfmmj@alvherre.pgsql> (raw)
In-Reply-To: <20170611022536.goef4cdbmgicye5g@alvherre.pgsql>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-bugs>

Alvaro Herrera wrote:

For some reason I sent a preliminary version of the email I was writing.
Some additional thoughts that were supposed to be in there:

> I also agree that restoreTwoPhaseData doesn't need to hold the lock,
> since we don't expect anything running concurrently, but that it's okay
> to hold it and makes the whole thing simpler.

It's okay to hold the lock for the whole duration of the function.

> We could try to apply an equivalent rationale to
> RecoverPreparedTransactions: even though we have already been running in
> HOT standby mode for a while, there's no possibility of concurrent
> activity either: since we exited recovery, master cannot write any more
> 2PC xacts, and we haven't yet set the flag that lets open sessions write
> WAL.  However, it seems mildly dangerous to run the bottom sections of
> the loop with the lock held, since it acquires other lwlocks and
> generally does a lot of crap.

Therefore, let's adopt your idea of acquiring the lock only for the
specific low-level calls that require it.  But the comment atop the loop
needs a lot of work to explain why it's doing that (i.e. how come it's
reading TwoPhaseState without a lock), as in my proposed patch.

(At first, I didn't really like this very much and wanted to add more
locking to that function, but it turned quite messy, so I back-tracked).

Thanks

-- 
Á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



view thread (30+ messages)  latest in thread

Message-ID: <20170611032448.f2da5epz5pnbfmmj@alvherre.pgsql>
Permalink:  ../20170611032448.f2da5epz5pnbfmmj@alvherre.pgsql/
Also on:    postgresql.org/message-id/20170611032448.f2da5epz5pnbfmmj@alvherre.pgsql

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-bugs@postgresql.org
  Cc: alvherre@2ndquadrant.com, michael.paquier@gmail.com, wangchuanting@huawei.com
  Subject: Re: Re: BUG #14680: startup process on standby encounter a deadlock of TwoPhaseStateLock when redo 2PC xlog
  In-Reply-To: <20170611032448.f2da5epz5pnbfmmj@alvherre.pgsql>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox