Обсуждение: src/test/regress/standby_schedule

Поиск
Список
Период
Сортировка

src/test/regress/standby_schedule

От
Thomas Munro
Дата:
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;



Re: src/test/regress/standby_schedule

От
Tom Lane
Дата:
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