pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed

From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: noah@leadboat.com
Cc: masao.fujii@oss.nttdata.com
Cc: tgl@sss.pgh.pa.us
Cc: pgsql-hackers@postgresql.org
Subject: Re: 001_rep_changes.pl stalls
Date: Mon, 20 Apr 2020 16:15:40 +0900 (JST)
Message-ID: <20200420.161540.916795157446565832.horikyota.ntt@gmail.com> (raw)
In-Reply-To: <20200418070142.GA1075445@rfd.leadboat.com>
References: <20200417054146.GA1061007@rfd.leadboat.com>
	<fba5fc85-205a-3aeb-9bf6-a124f762aa27@oss.nttdata.com>
	<20200418070142.GA1075445@rfd.leadboat.com>

At Sat, 18 Apr 2020 00:01:42 -0700, Noah Misch <noah@leadboat.com> wrote in 
> On Fri, Apr 17, 2020 at 05:06:29PM +0900, Kyotaro Horiguchi wrote:
> > At Fri, 17 Apr 2020 17:00:15 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in 
> > > By the way, if latch is consumed in WalSndLoop, succeeding call to
> > > WalSndWaitForWal cannot be woke-up by the latch-set.  Doesn't that
> > > cause missing wakeups? (in other words, overlooking of wakeup latch).
> > 
> > - Since the only source other than timeout of walsender wakeup is latch,
> > - we should avoid wasteful consuming of latch. (It is the same issue
> > - with [1]).
> > 
> > + Since walsender is wokeup by LSN advancement via latch, we should
> > + avoid wasteful consuming of latch. (It is the same issue with [1]).
> > 
> > 
> > > If wakeup signal is not remembered on walsender (like
> > > InterruptPending), WalSndPhysical cannot enter a sleep with
> > > confidence.
> 
> No; per latch.h, "What must be avoided is placing any checks for asynchronous
> events after WaitLatch and before ResetLatch, as that creates a race
> condition."  In other words, the thing to avoid is calling ResetLatch()
> without next examining all pending work that a latch would signal.  Each
> walsender.c WaitLatch call does follow the rules.

I didn't meant that, of course.  I thought of more or less the same
with moving the trigger from latch to signal then the handler sets a
flag and SetLatch().  If we use bare latch, we should avoid false
entering to sleep, which also makes thinks compolex.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

view thread (17+ messages)  latest in thread

Message-ID: <20200420.161540.916795157446565832.horikyota.ntt@gmail.com>
Permalink:  ../20200420.161540.916795157446565832.horikyota.ntt@gmail.com/
Also on:    postgresql.org/message-id/20200420.161540.916795157446565832.horikyota.ntt@gmail.com

copy link · copy postgr.es

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-hackers@postgresql.org
  Cc: horikyota.ntt@gmail.com, noah@leadboat.com, masao.fujii@oss.nttdata.com, tgl@sss.pgh.pa.us
  Subject: Re: 001_rep_changes.pl stalls
  In-Reply-To: <20200420.161540.916795157446565832.horikyota.ntt@gmail.com>

* 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