Additionally I've looked at the tests and I'm not sure but I don't think this arrangement is going to work. I don't have the time to run CLOBBER_CACHE and CLOBBER_CACHE_ALWAYS tests but I know they run *really* slowly. So the test can't just do a CHECKPOINT and then trust that the next few transactions will still be in the wal to decode later. There could have been many more timed checkpoints in between.
I think the way to do it is to create either a backup label or a replication slot. Then you can inspect the lsn of the label or slot and decode all transactions between that point and the current point. I also think you should try to have a wider set of wal records in that range to test decoding records with and without full page writes, with DDL records, etc. I do like that the tests don't actually have the decoded record info in the test though. But they can do a minimal effort to check that the records they think they're testing are actually being tested. Insert into a temporary table and then run a few queries with WHERE clauses to test for a heap insert, btree insert test the right relid is present, and test that a full page write is present (if full page writes are enabled I guess). You don't need an exhaustive set of checks because you're not testing that wal logging works properly, just that the tests aren't accidentally passing because they're not finding any interesting records.
