Re: Why is citext/regress failing on hamerkop?
От | Alexander Lakhin |
---|---|
Тема | Re: Why is citext/regress failing on hamerkop? |
Дата | |
Msg-id | 8ef50a21-8fa6-c470-e76f-cd7317db67d9@gmail.com обсуждение исходный текст |
Ответ на | Re: Why is citext/regress failing on hamerkop? (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: Why is citext/regress failing on hamerkop?
|
Список | pgsql-hackers |
Hello Thomas, 16.05.2024 04:32, Thomas Munro wrote: > On Thu, May 16, 2024 at 10:43 AM Thomas Munro <thomas.munro@gmail.com> wrote: >> Any chance you could test this version please Alexander? > Sorry, cancel that. v3 is not good. I assume it fixes the GSSAPI > thing and is superficially better, but it doesn't handle code that > calls twice in a row and ignores the first result (I know that > PostgreSQL does that occasionally in a few places), and it's also > broken if someone gets recv() = 0 (EOF), and then decides to wait > anyway. The only ways I can think of to get full reliable poll()-like > semantics is to do that peek every time, OR the complicated patch > (per-socket-workspace + intercepting recv etc). So I'm back to v2. I've tested v2 and can confirm that it works as v1, `vcregress check` passes with no failures on REL_16_STABLE, `meson test` with the basic configuration too. By the way, hamerkop is not configured to enable gssapi for HEAD [1] and I could not enable gss locally yet (just passing extra_lib_dirs, extra_include_dirs doesn't work for me). It looks like we need to find a way to enable it for meson to continue testing v17+ with GSS on Windows. [1] https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=hamerkop&dt=2024-05-12%2011%3A00%3A28&stg=configure Best regards, Alexander
В списке pgsql-hackers по дате отправления: