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
