Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Melanie Plageman <melanieplageman@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Peter Geoghegan <pg@bowt.ie>,
Heikki Linnakangas <hlinnaka@iki.fi>,
Pg Hackers <pgsql-hackers@postgresql.org>,
Andres Freund <andres@anarazel.de>, Noah Misch <noah@leadboat.com>
Date: 2024-07-22T22:36:34Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Test that vacuum removes tuples older than OldestXmin
- 2c0bc4765741 17.6 landed
- 303ba0573ce6 18.0 landed
- 80c34692e8e6 17.0 landed
- aa607980aee0 18.0 landed
-
Lower minimum maintenance_work_mem to 64kB
- 2eda3df9ad53 17.0 landed
- bbf668d66fbf 18.0 landed
-
Add accidentally omitted test to meson build file
- 9d198f4d3e3b 16.4 landed
-
Use DELETE instead of UPDATE to speed up vacuum test
- 924a08b76f5d 14.13 landed
- 9744fe24118b 15.8 landed
- 571e0ee40ebd 16.4 landed
-
Revert "Test that vacuum removes tuples older than OldestXmin"
- efcbb76efe40 18.0 landed
- 1a3e90948b50 17.0 landed
-
Ensure vacuum removes all visibly dead tuples older than OldestXmin
- fd4f12df5e46 17.0 landed
- 83c39a1f7f3f 18.0 landed
Melanie Plageman <melanieplageman@gmail.com> writes: > We've only run tests with this commit on some of the back branches for > some of these animals. Of those, I don't see any failures so far. So, > it seems the test instability is just related to trying to get > multiple passes of index vacuuming reliably with TIDStore. > AFAICT, all the 32bit machine failures are timeouts waiting for the > standby to catch up (mamba, gull, merswine). Unfortunately, the > failures on copperhead (a 64 bit machine) are because we don't > actually succeed in triggering a second vacuum pass. This would not be > fixed by a longer timeout. Ouch. This seems to me to raise the importance of getting a better way to test multiple-index-vacuum-passes. Peter argued upthread that we don't need a better way, but I don't see how that argument holds water if copperhead was not reaching it despite being 64-bit. (Did you figure out exactly why it doesn't reach the code?) > Because of this, I'm inclined to revert the test on 17 and master to > avoid distracting folks committing other work and seeing those animals > go red. Agreed as a short-term measure. regards, tom lane