Re: Testing LISTEN/NOTIFY more effectively

Hi,

On 2019-07-27 19:27:17 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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 ...

Yea. Although that'd could just be done in a local variable. Anyway,
it's obviously not important.

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

Yea, that's precisely what I was trying to refer to / suggesting. What I
think is happening is that both queries get sent to the server, we
PQisBusy();select() and figure out they're not done yet. On most
machines the raise NOTICE will have been processed by that time, after
it's a trivial query. But on prariedog (and I suspect even more likely
on valgrind / clobber cache animals), they're not that far yet. So we
send the blocking query, until we've seen that it blocks. But there's no
interlock guaranteeing that we'll have seen the notices before the
*other* connection has detected us blocking. As the blocking query is
more complex to plan and execute, that window isn't that small.

Polling for notices on the blocked connection before printing anything
ought to practically be reliable. Theoretically I think it still allows
for some reordering, e.g. because there was packet loss on one, but not
the other connection.

Greetings,

Andres Freund