Re: Why is src/test/modules/committs/t/002_standby.pl flaky? - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Why is src/test/modules/committs/t/002_standby.pl flaky?
Date
Msg-id CA+hUKGK1QszjvPC_bchaQ8-DUF4jMTyqxgXpsi4L8YhN=NLpcA@mail.gmail.com
Whole thread Raw
In response to Re: Why is src/test/modules/committs/t/002_standby.pl flaky?  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Why is src/test/modules/committs/t/002_standby.pl flaky?
List pgsql-hackers
On Thu, Jan 13, 2022 at 7:36 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> ... First I tried to use recv(fd, &c, 1,
> MSG_PEEK) == 0 to detect EOF, which seemed to me to be a reasonable
> enough candidate, but somehow it corrupts the stream (!?),

Ahh, that'd be because recv() and friends are redirected to our
wrappers in socket.c, where we use the overlapped Winsock API (that
is, async network IO), which is documented as not supporting MSG_PEEK.
OK then.

Andres and I chatted about this stuff off list and he pointed out
something else about the wrappers in socket.c: there are more paths in
there that work with socket events, which means more ways to lose the
precious FD_CLOSE event.  I don't know if any of those paths are
reachable in the relevant cases, but it does look a little bit like
the lack of graceful shutdown might have been hiding a whole class of
event tracking bug.



pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: relcache not invalidated when ADD PRIMARY KEY USING INDEX
Next
From: Julien Rouhaud
Date:
Subject: Re: Add sub-transaction overflow status in pg_stat_activity