Alvaro Herrera aba2184bed Reduce cost of test_decoding's new oldest_xmin test ... Change a whole-database VACUUM into doing just pg_attribute, which is the portion that verifies what we want it to do. The original formulation wastes a lot of CPU time, which leads the test to fail when runtime exceeds isolationtester timeout when it's super-slow, such as under CLOBBER_CACHE_ALWAYS. Per buildfarm member friarbird. It turns out that the previous shape of the test doesn't always detect the condition it is supposed to detect (on unpatched reorderbuffer code): the reason is that there is a good chance of encountering a xl_running_xacts record (logged every 15 seconds) before the checkpoint -- and because we advance the xmin when we receive that WAL record, and we *don't* advance the xmin twice consecutively without receiving a client message in between, that means the xmin is not advanced enough for the tuple to be pruned from pg_attribute by VACUUM. So the test would spuriously pass. The reason this test deficiency wasn't detected earlier is that HOT pruning removes the tuple anyway, even if vacuum leaves it in place, so the test correctly fails (detecting the coding mistake), but for the wrong reason. To fix this mess, run the s0_get_changes step twice before vacuum instead of once: this seems to cause the xmin to be advanced reliably, wreaking havoc with more certainty. Author: Arseny Sher Discussion: https://postgr.es/m/87h8lkuxoa.fsf@ars-thinkpad		2018-07-05 16:40:42 -04:00
..
binary.out
concurrent_ddl_dml.out
ddl.out
decoding_in_xact.out
decoding_into_rel.out
delayed_startup.out
messages.out
mxact.out
oldest_xmin.out	Reduce cost of test_decoding's new oldest_xmin test	2018-07-05 16:40:42 -04:00
ondisk_startup.out
permissions.out
prepared.out
replorigin.out
rewrite.out
slot.out
snapshot_transfer.out
spill.out
time.out
toast.out
truncate.out
xact.out