Horton
Menu

Re: Why is citext/regress failing on hamerkop?

Alexander Lakhin <exclusion@gmail.com>

View thread
From: Alexander Lakhin <exclusion@gmail.com>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andrew Dunstan <andrew@dunslane.net>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-05-16T12:00:00Z
Lists: 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

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Small refactoring around ExecCreateTableAs().

  2. Skip citext_utf8 test on Windows.

  3. Fix lost Windows socket EOF events.

  4. Enable routine running of citext's UTF8-specific test cases.

  5. Drops in the CreateProcess calls for Win32 (essentially wrapping up the