Re: Why is citext/regress failing on hamerkop?

Thomas Munro <thomas.munro@gmail.com>

From: Thomas Munro <thomas.munro@gmail.com>
To: Alexander Lakhin <exclusion@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andrew Dunstan <andrew@dunslane.net>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-05-15T21:46:41Z
Lists: pgsql-hackers

Attachments

On Wed, May 15, 2024 at 6:00 PM Alexander Lakhin <exclusion@gmail.com> wrote:
> 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.

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.

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