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

From Tom Lane
Subject Re: Why is src/test/modules/committs/t/002_standby.pl flaky?
Date
Msg-id 1693369.1641746970@sss.pgh.pa.us
Whole thread Raw
In response to Re: Why is src/test/modules/committs/t/002_standby.pl flaky?  (Alexander Lakhin <exclusion@gmail.com>)
List pgsql-hackers
Alexander Lakhin <exclusion@gmail.com> writes:
> 09.01.2022 04:17, Tom Lane wrote:
>> ... wait a minute.  After some more study of the buildfarm logs,
>> it was brought home to me that these failures started happening
>> just after 6051857fc went in:

> I've managed to reproduce this failure too.
> Removing "shutdown(MyProcPort->sock, SD_SEND);" doesn't help here, so
> the culprit is exactly "closesocket(MyProcPort->sock);".

Ugh.  Did you try removing the closesocket and keeping shutdown?
I don't recall if we tried that combination before.

> ...  I'm not sure where to
> place this check, maybe it's better to move it up to
> libpqrcv_PQgetResult() to minimize it's footprint or to find less
> Windows-specific approach, but I'd prefer a client-side fix anyway, as
> graceful closing a socket by a server seems a legitimate action.

What concerns me here is whether this implies that other clients
(libpq, jdbc, etc) are going to need changes as well.  Maybe
libpq is okay, because we've not seen failures of the isolation
tests that use pg_cancel_backend(), but still it's worrisome.
I'm not entirely sure whether the isolationtester would notice
that a connection that should have died didn't.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: null iv parameter passed to combo_init()
Next
From: Tom Lane
Date:
Subject: Re: null iv parameter passed to combo_init()