On 4/23/21 1:37 AM, Thomas Munro wrote:
> Hi,
>
> We have automated tests for many specific replication and recovery
> scenarios, but nothing that tests replay of a wide range of records.
> People working on recovery code often use installcheck (presumably
> along with other custom tests) to exercise it, sometimes with
> wal_consistency_check enabled. So, why don't we automate that? Aside
> from exercising the WAL decoding machinery (which brought me here),
> that'd hopefully provide some decent improvements in coverage of the
> various redo routines, many of which are not currently exercised at
> all.
>
> I'm not quite sure where it belongs, though. The attached initial
> sketch patch puts it under rc/test/recovery near other similar things,
> but I'm not sure if it's really OK to invoke make -C ../regress from
> here. I copied pg_update/test.sh's trick of using a different
> outputdir to avoid clobbering a concurrent run under src/test/regress,
> and I also needed to invent a way to stop it from running the cursed
> tablespace test (deferring startup of the standby also works but eats
> way too much space, which I learned after blowing out a smallish
> development VM's disk). Alternatively, we could put it under
> src/test/regress, which makes some kind of logical sense, but it would
> make a quick "make check" take more than twice as long. Perhaps it
> could use a different target, one that check-world somehow reaches but
> not check, and that also doesn't seem great. Ideas on how to
> structure this or improve the perl welcome.
Nice, I like adding a skip-tests option to pg_regress.
The perl looks ok - I assume those
print "standby 1: $result\n";
lines are there for debugging. Normally you would just process $result
using the Test::More functions
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
