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-15T06:00:00Z
Lists: pgsql-hackers 
15.05.2024 01:26, Thomas Munro wrote:
> OK, so we know what the problem is here.  Here is the simplest
> solution I know of for that problem.  I have proposed this in the past
> and received negative feedback because it's a really gross hack.  But
> I don't personally know what else to do about the back-branches (or
> even if that complex solution is the right way forward for master).
> The attached kludge at least has the [de]merit of being a mirror image
> of the kludge that follows it for the "opposite" event.  Does this fix
> it?

Yes, I see that abandoned GSS connections are closed immediately, as
expected. I have also confirmed that `meson test` with the basic
configuration passes on REL_16_STABLE. So from the outside, the fix
looks good to me.

Thank you for working on this!

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