Re: WL_SOCKET_ACCEPT fairness on Windows - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: WL_SOCKET_ACCEPT fairness on Windows
Date
Msg-id CA+hUKG+zoJVLcF=YK2HGMzhNiuLjYQ4utPNwfTcX=O6VY--YnQ@mail.gmail.com
Whole thread Raw
In response to Re: WL_SOCKET_ACCEPT fairness on Windows  ("Jonathan S. Katz" <jkatz@postgresql.org>)
Responses Re: WL_SOCKET_ACCEPT fairness on Windows
Re: WL_SOCKET_ACCEPT fairness on Windows
List pgsql-hackers
On Wed, May 17, 2023 at 2:57 AM Jonathan S. Katz <jkatz@postgresql.org> wrote:
> On 3/31/23 11:00 PM, Thomas Munro wrote:
> >>> I mention this now because I'm not sure whether to consider this an
> >>> 'open item' for 16, or merely an enhancement for 17.  I guess the
> >>> former, because someone might call that a new denial of service
> >>> vector.  On the other hand, if you fill up the listen queue for socket
> >>> 1 with enough vigour, you're also denying service to socket 1, so I
> >>> don't know if it's worth worrying about.  Opinions on that?
> >>
> >> I'm not sure either. It doesn't strike me as a particularly relevant
> >> bottleneck. And the old approach of doing more work for every single
> >> connection also made many connections worse, I think?
> >
> > Alright, let's see if anyone else thinks this is worth fixing for 16.
>
> [RMT hat]
>
> Given this has sat for a bit, I wanted to see if any of your thinking
> has changed on whether this should be fixed for v16 or v17. I have
> personally not formed an opinion yet, but per the current discussion, it
> seems like this could wait?

Yeah.  No one seems to think this is worth worrying about (please
speak up if you do).  I'll go ahead and remove this from the open item
lists now, but I'll leave the patch in the CF for 17, to see if a
Windows hacker/tester thinks it's a worthwhile improvement.



pgsql-hackers by date:

Previous
From: Melanie Plageman
Date:
Subject: Re: Memory leak from ExecutorState context?
Next
From: Melanie Plageman
Date:
Subject: Re: Memory leak from ExecutorState context?