Re: BackgroundPsql swallowing errors on windows

From: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Daniel Gustafsson <daniel(at)yesql(dot)se>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Noah Misch <noah(at)leadboat(dot)com>
Subject: Re: BackgroundPsql swallowing errors on windows
Date: 2025-02-14 17:52:24
Message-ID: CAOYmi+mK8s7rdL9_28VJuCh3-mz-4vv9N-1s1OYJrn85cjPN_g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Feb 14, 2025 at 8:53 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> commit 70291a3c66e
> Author: Michael Paquier <michael(at)paquier(dot)xyz>
> Date: 2024-11-07 12:11:27 +0900
>
> Improve handling of empty query results in BackgroundPsql::query()
>
> commit ba08edb0654
> Author: Michael Paquier <michael(at)paquier(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-02-14 18:01:32 New buildfarm animals with FIPS mode enabled
Previous Message Tomas Vondra 2025-02-14 17:50:10 Re: BitmapHeapScan streaming read user and prelim refactoring