src/test/regress/standby_schedule

Started by Thomas Munroabout 6 years ago2 messageshackers
Jump to latest
#1Thomas Munro
thomas.munro@gmail.com

Hello,

I guess no human or machine ever runs $SUBJECT, because when I tried
it while hunting down users of txid_XXX functions, it failed (see
end). To run it, you need a primary/standby pair, here 5441/5442, and
then:

PGPORT=5441 psql postgres -f sql/hs_primary_setup.sql
PGPORT=5442 ./pg_regress --use-existing --dbname=postgres --schedule
standby_schedule

Perhaps the output changed in January with commit 2eb34ac3. Easy to
fix, but I wonder if anyone has a good idea for how to get check-world
to run it (probably via the "recovery" stuff).

diff -U3 /home/tmunro/projects/postgresql/src/test/regress/expected/hs_standby_disallowed.out
/home/tmunro/projects/postgresql/src/test/regress/results/hs_standby_disallowed.out
--- /home/tmunro/projects/postgresql/src/test/regress/expected/hs_standby_disallowed.out
   2020-03-24 09:02:24.835023971 +1300
+++ /home/tmunro/projects/postgresql/src/test/regress/results/hs_standby_disallowed.out
2020-04-03 13:09:24.339672898 +1300
@@ -64,7 +64,7 @@
 (1 row)
 COMMIT PREPARED 'foobar';
-ERROR:  COMMIT PREPARED cannot run inside a transaction block
+ERROR:  cannot execute COMMIT PREPARED during recovery
 ROLLBACK;
 BEGIN;
 SELECT count(*) FROM hs1;
@@ -86,7 +86,7 @@
 (1 row)
 ROLLBACK PREPARED 'foobar';
-ERROR:  ROLLBACK PREPARED cannot run inside a transaction block
+ERROR:  cannot execute ROLLBACK PREPARED during recovery
 ROLLBACK;
 -- Locks
 BEGIN;
#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Thomas Munro (#1)
Re: src/test/regress/standby_schedule

Thomas Munro <thomas.munro@gmail.com> writes:

I guess no human or machine ever runs $SUBJECT, because when I tried
it while hunting down users of txid_XXX functions, it failed (see
end). To run it, you need a primary/standby pair, here 5441/5442, and
then:

PGPORT=5441 psql postgres -f sql/hs_primary_setup.sql
PGPORT=5442 ./pg_regress --use-existing --dbname=postgres --schedule
standby_schedule

Perhaps the output changed in January with commit 2eb34ac3. Easy to
fix, but I wonder if anyone has a good idea for how to get check-world
to run it (probably via the "recovery" stuff).

That stuff is very very ancient. I'd suggest nuking it and writing
an equivalent TAP test, assuming that there's anything it does that's
not already covered by our existing TAP tests.

regards, tom lane