Re: Backporting BackgroundPsql - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Backporting BackgroundPsql
Date
Msg-id 202406260012.qon4sbgs7iir@alvherre.pgsql
Whole thread Raw
In response to Re: Backporting BackgroundPsql  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Backporting BackgroundPsql
List pgsql-hackers
On 2024-Jun-25, Tom Lane wrote:

> Daniel Gustafsson <daniel@yesql.se> writes:

> > However, since Andrew is actively aiming to replace all of this shortly, should
> > we wait a see where that lands to avoid having to backport another library
> > change?
> 
> I would like to see what he comes up with ... but is it likely to
> be something we'd risk back-patching?

FWIW I successfully used the preliminary PqFFI stuff Andrew posted to
write a test program for bug #18377, which I think ended up being better
than with BackgroundPsql, so I think it's a good way forward.  As for
back-patching it, I suspect we're going to end up backpatching the
framework anyway just because we'll want to have it available for
backpatching future tests, even if we keep a backpatch minimal by doing
only the framework and not existing tests.

I also backpatched the PqFFI and PostgreSQL::Session modules to older PG
branches, to run my test program there.  This required only removing
some lines from PqFFI.pm that were about importing libpq functions that
older libpq didn't have.

Of course, the PostgreSQL::Session stuff is not ready yet, so if we want
this test in the tree soon, I don't think we should wait.


I'll note, though, that Test::More doesn't work terribly nicely with
perl threads, but that only relates to my test program and not to PqFFI.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"La gente vulgar sólo piensa en pasar el tiempo;
el que tiene talento, en aprovecharlo"



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: CI, macports, darwin version problems
Next
From: Michael Paquier
Date:
Subject: Re: Backporting BackgroundPsql