Re: BF animal malleefowl reported an failure in 001_password.pl
Thomas Munro <thomas.munro@gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-01-14T11:35:43Z
Lists: pgsql-hackers
Attachments
- 0001-Prioritize-latches-over-connections-in-the-postmaste.patch (text/x-patch) patch 0001
On Sat, Jan 14, 2023 at 10:29 PM Thomas Munro <thomas.munro@gmail.com> wrote: > But if that's the general idea, I suppose there would be two ways to > give higher priority to signals/latches that arrive in the same set of > events: (1) scan the events array twice (for latches then > connections), or (2) check our pending flags every time through the > output events loop, at the top, even for connection events (ie just > move some lines up a bit). Here's a sketch of the first idea. I also coded up the second idea (basically: when nevents > 1, behave as though the latch has been set every time through the loop, and then also check for WL_SOCKET_ACCEPT), but I'm not sure I like it (it's less clear to read, harder to explain, and I'm also interested in exploring alternative ways to receive signals other than with handlers that set these flags so I'm not sure I like baking in the assumption that we can test the flags without having received a corresponding event). I'm going to be AFK for a day or so and I'd like to see if we can collect some more evidence about this and maybe repro first so I'll wait for a bit.
Commits
-
Process pending postmaster work before connections.
- 239b1753421c 16.0 landed