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: <20190727231826.g34yqkzj53ey46tl@alap3.anarazel.de>
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>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Sat, 27 Jul 2019 16:18:26 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <10165.1564270037.1@sss.pgh.pa.us>
Date: Sat, 27 Jul 2019 19:27:17 -0400
Message-ID: <10166.1564270037@sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> We could of course just send the pids in binary ;). No, not worth it
> just to avoid a small redundant array ;)

IIRC, we'd have to do htonl on them, so we'd still end up with
two representations ...

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

			regards, tom lane