Horton

Re: BackgroundPsql swallowing errors on windows

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: Andres Freund <andres@anarazel.de>
Cc: Jacob Champion <jacob.champion@enterprisedb.com>, 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-16T23:52:58Z
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

On Sat, Feb 15, 2025 at 04:13:37PM -0500, Andres Freund wrote:
> 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

(Side question entirely unrelated as I'm reading that..)
What's your magic recipe for showing up with commit format?  The best
thing I could come up with was to use "(14,trunc)%H" in format.pretty,
but it has the idea of showing two dots at the end of the commit ID.

>>> 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
>> 
>> 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.

No issues with ba08edb0654.

>> 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.

FWIW, Debian Search reports that the only references to BackgroundPsql
are in the Postgres tree, so backpatching 70291a3c66e does not worry
me.  Github has more much references due to forked code or direct
copies of BackgroundPsql.pn modified for the purpose of the code.
--
Michael