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

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Magnus Hagander <magnus@hagander.net>
Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: Mark Dilger <hornschnorter@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Windows buildfarm members vs. new async-notify isolation test
Date: Sun, 08 Dec 2019 09:53:14 -0500
Message-ID: <28011.1575816794@sss.pgh.pa.us> (raw)
In-Reply-To: <CAA4eK1+eo0t20xkPX9-WGdO+tDwEv9krba-R2F3OSqyLAWW59w@mail.gmail.com>
References: <32745.1575303812@sss.pgh.pa.us>
	<7221b3b4-fc7f-404d-5cf6-830d3aa6800d@2ndQuadrant.com>
	<362bca0b-1c1c-c760-ab19-b5d9a14c69ea@gmail.com>
	<13003.1575391248@sss.pgh.pa.us>
	<CAA4eK1+qevZ=sB1nW05_gkiHLWjUU0psNPiutFnQi=+aCztLXA@mail.gmail.com>
	<25746.1575436347@sss.pgh.pa.us>
	<CAA8=A78X-0vVd5tk7r=Z7yEWW5Vy1=46q7wjZaOa8Xaed5FooQ@mail.gmail.com>
	<CAA4eK1+HOFzs=-MHDz6ef936KuuHJBxZbHEi7xt9TBqgHNO9GQ@mail.gmail.com>
	<e1eb7182-a487-42f1-e113-4e5758e8ceef@2ndQuadrant.com>
	<20102.1575675105@sss.pgh.pa.us>
	<CAA4eK1LRwxr51JuXsgpmCA+-uswCHiGvhZ88jPz8VeJxfyv65g@mail.gmail.com>
	<30330.1575739251@sss.pgh.pa.us>
	<4412.1575748586@sss.pgh.pa.us>
	<CAA4eK1KpRMRJG0krbiL8sUA9wZTVwvoHejEkJK2sVH2idG-rSQ@mail.gmail.com>
	<CAA4eK1+eo0t20xkPX9-WGdO+tDwEv9krba-R2F3OSqyLAWW59w@mail.gmail.com>

Amit Kapila <amit.kapila16@gmail.com> writes:
> IIUC, once the dispatch thread has queued the signal
> (pg_queue_signal), the next CHECK_FOR_INTERRUPTS by the main thread
> will execute the signal.  So, if we move pg_queue_signal() before we
> do WriteFile in pg_signal_dispatch_thread(), this race condition will
> be closed.  Now, we might not want to do this as that will add some
> more time (even though very less) before notify on the other side can
> finish or maybe there is some technical problem with this idea which I
> am not able to see immediately.

Hmm.  Certainly worth trying to see if it resolves the failure on
Andrew's machines.

It's not real hard to believe that TransactNamedPipe could be
"optimized" so that it preferentially schedules the client thread
once the handshake is done, not the server thread (based on some
heuristic claim that the former is probably an interactive process
and the latter less so).  In that situation, we'd proceed on with
the signal not really delivered, and there is nothing guaranteeing
that it will be delivered anytime soon --- the rest of the test
can make progress regardless of whether that thread ever gets
scheduled again.  So, as long as we've got this handshake mechanism,
it seems like it'd be a good thing for the ack to indicate that
the signal was *actually* delivered (by setting the recipient's
flag bit) and not just that it'll probably get delivered eventually.

I remain a bit unsure that we actually need the handshaking business
at all --- I doubt that Unix signals provide any guarantee of synchronous
delivery on most platforms.  (If I'm reading the POSIX spec correctly,
it only requires synchronous delivery when a thread signals itself.)
But the existence of this unsynchronized thread in the Windows
implementation sure seems like a dubious thing, now that you
point it out.

			regards, tom lane





view thread (27+ messages)  latest in thread

Message-ID: <28011.1575816794@sss.pgh.pa.us>
Permalink:  ../28011.1575816794@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/28011.1575816794@sss.pgh.pa.us

 · 

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: tgl@sss.pgh.pa.us, amit.kapila16@gmail.com, magnus@hagander.net, andrew.dunstan@2ndquadrant.com, hornschnorter@gmail.com, pgsql-hackers@lists.postgresql.org
  Subject: Re: Windows buildfarm members vs. new async-notify isolation test
  In-Reply-To: <28011.1575816794@sss.pgh.pa.us>

* 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