Re: REL_15_STABLE: pgbench tests randomly failing on CI, Windows only

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: REL_15_STABLE: pgbench tests randomly failing on CI, Windows only
Date: 2023-10-09 05:00:03
Message-ID: CAKFQuwaYZWpXTegE=YwvxhTA1iZ-bMwnebmsj6R49rzi2ibTkA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Oct 8, 2023 at 9:10 PM Noah Misch <noah(at)leadboat(dot)com> wrote:

>
> I didn't think of any phrasing that clearly explained things without the
> reader consulting the code. I considered these:
>
> "socket file descriptor out of range: %d" [what range?]
>
>
Quick drive-by...but it seems that < 0 is a distinctly different problem
than exceeding FD_SETSIZE. I'm unsure what would cause the former but the
error for the later seems like:

error: "Requested socket file descriptor %d exceeds connection limit of
%d", fd, FD_SETSIZE-1
hint: Reduce the requested number of concurrent connections

In short, the concept of range doesn't seem applicable here. There is an
error state at the max, and some invalid system state condition where the
position within a set is somehow negative. These should be separated -
with the < 0 check happening first.

And apparently this condition isn't applicable when dealing with jobs in
connect_slot? Also, I see that for connections we immediately issue FD_SET
so this check on the boundary of the file descriptor makes sense. But the
remaining code in connect_slot doesn't involve FD_SET so the test for the
file descriptor falling within its maximum seems to be coming out of
nowhere. Likely this is all good, and the lack of symmetry is just due to
the natural progressive development of the code, but it stands out to the
uninitiated looking at this patch.

David J.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message "Anitha S" 2023-10-09 05:01:51 Re: Two Window aggregate node for logically same over clause
Previous Message Tom Lane 2023-10-09 04:37:13 Re: Making aggregate deserialization (and WAL receive) functions slightly faster