Re: BackgroundPsql swallowing errors on windows

Jacob Champion <jacob.champion@enterprisedb.com>

From: Jacob Champion <jacob.champion@enterprisedb.com>

To: Andres Freund <andres@anarazel.de>

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-14T17:52:24Z

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 →

tests: BackgroundPsql: Fix potential for lost errors on windows
- bb2bf22761e1 13.21 landed
- c21ebcca7965 14.18 landed
- 70b650d18553 15.13 landed
- 4c9397c374d9 16.9 landed
- f61769adaa62 17.5 landed
- 8b886a4e3488 18.0 landed
Improve handling of empty query results in BackgroundPsql::query()
- 70291a3c66ec 18.0 cited
Extend Cluster.pm's background_psql() to be able to start asynchronously
- ba08edb06545 18.0 cited

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, 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. If we're
concerned about the second for any reason, the only conflicting part
should be the name and documentation of wait_connect, right?

--Jacob