Re: Backporting BackgroundPsql
Melanie Plageman <melanieplageman@gmail.com>
From: Melanie Plageman <melanieplageman@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Daniel Gustafsson <daniel@yesql.se>, Andrew Dunstan <andrew@dunslane.net>, Amit Kapila <amit.kapila16@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Mikael Kjellström <mikael.kjellstrom@gmail.com>
Date: 2024-06-25T15:34:22Z
Lists: pgsql-hackers
On Tue, Jun 25, 2024 at 7:40 AM Andres Freund <andres@anarazel.de> wrote: > > 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... +1 to backporting background psql! I'm also okay with 2 or 3. But note that for 2, there are several tests with skip_all and at least one of them uses background_psql (031_recovery_conflict.pl), so we'll just have to remember to update those. I assume that is easy enough to do if you grep for background_psql -- but, just in case you were going to be 100% test-driven :) - Melanie
Commits
-
Fix missing installation/uninstallation rules for BackgroundPsql.pm
- 241ef53b6a95 12.20 landed
- 0d80e59a1b2c 13.16 landed
- 1185be355462 14.13 landed
- 9d7506a2f7cb 15.8 landed
-
Backport BackgroundPsql perl test module
- 4b467a6581af 12.20 landed
- 12f327b210b3 13.16 landed
- 31877cd8ec8c 14.13 landed
- d5fd7865f068 15.8 landed
- 187b8991f70f 16.4 landed
-
Add missing uninstallation rule for BackgroundPsql.pm
- 7039c7cff673 16.0 cited
-
Fix missing installation rules for BackgroundPsql.pm
- a4c17c86176c 16.0 cited
-
Skip \password TAP test on old IPC::Run versions
- 2e57ffe12f6b 16.0 landed
-
Test SCRAM iteration changes with psql \password
- bf5a894c5571 16.0 landed
-
Refactor background psql TAP functions
- 664d757531e1 16.0 landed