Re: Backporting BackgroundPsql - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Backporting BackgroundPsql
Date
Msg-id 20240625114038.jzd2g52ijnfhtfp7@alap3.anarazel.de
Whole thread Raw
In response to Backporting BackgroundPsql  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: Backporting BackgroundPsql
Re: Backporting BackgroundPsql
List pgsql-hackers
Hi,

On 2024-06-25 13:26:23 +0300, Heikki Linnakangas wrote:
> While fixing a recent bug on visibility on a standby [1], I wrote a
> regression test that uses BackgroundPsql to run some queries in a
> long-running psql session. The problem is that that was refactored in v17,
> commit 664d757531. The test I wrote for v17 doesn't work as it is on
> backbranches. Options:
> 
> 1. Write the new test differently on backbranches. Before 664d757531, the
> test needs to work a lot harder to use the background psql session, calling
> pump() etc. That's doable, but as noted in the discussion that led to
> 664d757531, it's laborious and error-prone.
> 
> 2. Backport commit 664d757531. This might break out-of-tree perl tests that
> use the background_psql() function. I don't know if any such tests exist,
> and they would need to be changed for v17 anyway, so that seems acceptable.
> Anyone aware of any extensions using the perl test modules?
> 
> 3. Backport commit 664d757531, but keep the existing background_psql()
> function unchanged. Add a different constructor to get the v17-style
> BackgroundPsql session, something like "$node->background_psql_new()".
> 
> I'm leaning towards 3. We might need to backport more perl tests that use
> background_psql() in the future, backporting the test module will make that
> easier.
> 
> Thoughts?

Yes, I've wished for this a couple times. I think 2 or 3 would be reasonable.
I think 1) often just leads to either tests not being written or being
fragile...

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Meson far from ready on Windows
Next
From: Michail Nikolaev
Date:
Subject: Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY