Horton

Re: BackgroundPsql swallowing errors on windows

Andres Freund <andres@anarazel.de>

View thread
From: Andres Freund <andres@anarazel.de>
To: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: Daniel Gustafsson <daniel@yesql.se>, Michael Paquier <michael.paquier@gmail.com>, Heikki Linnakangas <heikki.linnakangas@iki.fi>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Noah Misch <noah@leadboat.com>
Date: 2025-02-15T21:13:37Z
Lists: pgsql-hackers

Commits

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

  1. tests: BackgroundPsql: Fix potential for lost errors on windows

  2. Improve handling of empty query results in BackgroundPsql::query()

  3. Extend Cluster.pm's background_psql() to be able to start asynchronously

Hi,

On 2025-02-14 09:52:24 -0800, Jacob Champion wrote:
> On Fri, Feb 14, 2025 at 8:53 AM Andres Freund <andres@anarazel.de> wrote:
> > commit 70291a3c66e
> > Author: Michael Paquier <michael@paquier.xyz>
> > Date:   2024-11-07 12:11:27 +0900
> >
> >     Improve handling of empty query results in BackgroundPsql::query()
> >
> > commit ba08edb0654
> > Author: Michael Paquier <michael@paquier.xyz>
> > Date:   2024-11-06 15:31:14 +0900
> >
> >     Extend Cluster.pm's background_psql() to be able to start asynchronously
> >
> >
> > Particularly the former makes it hard to backpatch, as it's a behavioural
> > difference that really interacts with the problems described in this thread.
> >
> > Michael, Jacob, thoughts?
> 
> I think both should be backpatchable without too much risk

I think so too. Obviously it'll have to wait until later next week due to the
new minor releases, but after that I think we should backpatch them.


> though it's possible that there are more useless ok() calls in back branches
> that would need to be touched when the first patch goes back.

FWIW, I don't really agree that such ok() calls are useless, they do make the
output of the test more readable, particularly if the test ends up hanging.
But that's really just an aside.


> If we're concerned about the second for any reason, the only conflicting
> part should be the name and documentation of wait_connect, right?

It doesn't seem concerning to me either.  The first commit seems much more
likely to cause trouble and even that seems ok.  Even if it were to cause
problem for an extension (which I think is rather unlikely), it shouldn't be
too hard to fix.

Greetings,

Andres Freund