From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org, Noah Misch <noah(at)leadboat(dot)com> |
Subject: | Re: BackgroundPsql swallowing errors on windows |
Date: | 2025-02-14 18:52:19 |
Message-ID: | 2mxs2zbon5orhp4mfu3yli6adndrhnf72otbvdgffimzo3ue2c@ucr2zcdqcvkx |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2025-02-14 12:14:55 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2025-02-14 08:14:45 -0500, Andrew Dunstan wrote:
> >> ... If there is interest I will
> >> bring the work up to date, and maybe we can introduce this early in the v19
> >> cycle. It would significantly reduce our dependency on IPC::Run, especially
> >> the pump() stuff.
>
> > I definitely am interested.
>
> +1. Would there be a chance of removing our use of IPC::Run entirely?
> There'd be a lot to like about that.
Unfortunately I doubt it'd get us that close to that.
We do have several tests that intentionally involve psql,
e.g. 010_tab_completion.pl, 001_password.pl. Presumably those would continue
to use something like BackgroundPsql.pm, even if we had a sane way to have
longrunning connections in tap tests.
There also are a bunch of things we use IPC::Run to run synchronously, we
probably could replace most of those without too much pain. The hardest
probably would be timeout handling.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2025-02-14 19:13:04 | Re: [Feature Request] INSERT FROZEN to Optimize Large Cold Data Imports and Migrations |
Previous Message | Andres Freund | 2025-02-14 18:44:36 | Re: BitmapHeapScan streaming read user and prelim refactoring |