From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Testing LISTEN/NOTIFY more effectively
In-reply-to: <10166.1564270037@sss.pgh.pa.us>
References: <31304.1564246011@sss.pgh.pa.us>
 <20190727174202.jiwr4jgp3x7gvp22@alap3.anarazel.de>
 <5720.1564249986@sss.pgh.pa.us> <29162.1564266052@sss.pgh.pa.us>
 <20190727231826.g34yqkzj53ey46tl@alap3.anarazel.de>
 <10166.1564270037@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Sat, 27 Jul 2019 19:27:17 -0400"
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
Content-ID: <13330.1564271066.0@sss.pgh.pa.us>
Date: Sat, 27 Jul 2019 19:45:15 -0400
Message-ID: <13589.1564271115@sss.pgh.pa.us>
Precedence: bulk

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <13330.1564271066.1@sss.pgh.pa.us>

I wrote:
> Andres Freund <andres@anarazel.de> writes:
>> Hm. I wonder if all that's happening with prairedog is that the notice
>> is sent a bit later. I think that could e.g. conceivably happen because
>> it TCP_NODELAY isn't supported on prariedog? Or just because the machine
>> is very slow?

> The notices (not notifies) are coming out in the opposite order from
> expected.  I haven't really thought hard about what's causing that;
> it seems odd, because isolationtester isn't supposed to give up waiting
> for a session until it's visibly blocked according to pg_locks.  Maybe
> it needs to recheck for incoming data once more after seeing that?

Ah-hah, that seems to be the answer.  With the attached patch I'm
getting reliable-seeming passes on prairiedog.

			regards, tom lane


------- =_aaaaaaaaaa0
Content-Type: text/x-diff; name="fix-notice-before-waiting.patch";
	charset="us-ascii"
Content-ID: <13330.1564271066.2@sss.pgh.pa.us>
Content-Description: fix-notice-before-waiting.patch
Content-Transfer-Encoding: quoted-printable

diff --git a/src/test/isolation/isolationtester.c b/src/test/isolation/iso=
lationtester.c
index 6ab19b1..e97fef1 100644
*** a/src/test/isolation/isolationtester.c
--- b/src/test/isolation/isolationtester.c
*************** try_complete_step(Step *step, int flags)
*** 752,757 ****
--- 752,777 ----
  =

  				if (waiting)	/* waiting to acquire a lock */
  				{
+ 					/*
+ 					 * Since it takes time to perform the lock-check query,
+ 					 * some data --- notably, NOTICE messages --- might have
+ 					 * arrived since we looked.  We should do PQconsumeInput
+ 					 * to process any such messages, and we might as well then
+ 					 * check PQisBusy, though it's unlikely to succeed.
+ 					 */
+ 					if (!PQconsumeInput(conn))
+ 					{
+ 						fprintf(stderr, "PQconsumeInput failed: %s\n",
+ 								PQerrorMessage(conn));
+ 						exit(1);
+ 					}
+ 					if (!PQisBusy(conn))
+ 						break;
+ =

+ 					/*
+ 					 * conn is still busy, so conclude that the step really is
+ 					 * waiting.
+ 					 */
  					if (!(flags & STEP_RETRY))
  						printf("step %s: %s <waiting ...>\n",
  							   step->name, step->sql);

------- =_aaaaaaaaaa0--