From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Why is citext/regress failing on hamerkop? |
Date: | 2024-05-15 22:43:06 |
Message-ID: | CA+hUKGLMAi0zAgES=AQUJ6yTd3qfVhnY2O607r1WpKTFY2Ry6w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, May 16, 2024 at 9:46 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> Alright, unless anyone has an objection or ideas for improvements, I'm
> going to go ahead and back-patch this slightly tidied up version
> everywhere.
Of course as soon as I wrote that I thought of a useful improvement
myself: as far as I can tell, you only need to do the extra poll on
the first wait for WL_SOCKET_READABLE for any given WaitEventSet. I
don't think it's needed for later waits done by long-lived
WaitEventSet objects, so we can track that with a flag. That avoids
adding new overhead for regular backend socket waits after
authentication, it's just in these code paths that do a bunch of
WaitLatchOrSocket() calls that we need to consider FD_CLOSE events
lost between the cracks.
I also don't know if the condition should include "&& received == 0".
It probably doesn't make much difference, but by leaving that off we
don't have to wonder how peeking interacts with events, ie if it's a
problem that we didn't do the "reset" step. Thinking about that, I
realised that I should probably set reset = true in this new return
path, just like the "normal" WL_SOCKET_READABLE notification path,
just to be paranoid. (Programming computers you don't have requires
extra paranoia.)
Any chance you could test this version please Alexander?
Attachment | Content-Type | Size |
---|---|---|
v3-0001-Fix-FD_CLOSE-socket-event-hangs-on-Windows.patch | application/octet-stream | 3.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2024-05-15 23:07:11 | Re: Introduce new multi insert Table AM and improve performance of various SQL commands with it for Heap AM |
Previous Message | Michael Paquier | 2024-05-15 22:13:20 | Re: Fix src/test/subscription/t/029_on_error.pl test when wal_debug is enabled |