A test for replay of regression tests
От | Thomas Munro |
---|---|
Тема | A test for replay of regression tests |
Дата | |
Msg-id | CA+hUKGKpRWQ9SxdxxDmTBCJoR0YnFpMBe7kyzY8SUQk+Heskxg@mail.gmail.com обсуждение исходный текст |
Ответы |
RE: A test for replay of regression tests
Re: A test for replay of regression tests Re: A test for replay of regression tests |
Список | pgsql-hackers |
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.
Вложения
В списке pgsql-hackers по дате отправления: