mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-09-14 03:39:39 +02:00
301b2a1aad
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 |
||
|---|---|---|
| .. | ||
| 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 | ||
| ondisk_startup.out | ||
| permissions.out | ||
| prepared.out | ||
| replorigin.out | ||
| rewrite.out | ||
| snapshot_transfer.out | ||
| spill.out | ||
| time.out | ||
| toast.out | ||
| xact.out | ||