Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin
Melanie Plageman <melanieplageman@gmail.com>
From: Melanie Plageman <melanieplageman@gmail.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Robert Haas <robertmhaas@gmail.com>,
Pg Hackers <pgsql-hackers@postgresql.org>, Andres Freund <andres@anarazel.de>, Noah Misch <noah@leadboat.com>
Date: 2024-06-24T20:58:09Z
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
On Mon, Jun 24, 2024 at 4:51 PM Peter Geoghegan <pg@bowt.ie> wrote: > > On Mon, Jun 24, 2024 at 4:36 PM Robert Haas <robertmhaas@gmail.com> wrote: > > I thought the idea was that the GlobalVisTest stuff would force a > > recalculation now and then, but maybe it doesn't actually do that? > > It definitely can do that. Just not in a way that meaningfully > increases the number of heap tuples that we can recognize as DEAD and > remove. At least not currently. > > > Suppose process A begins a transaction, acquires an XID, and then goes > > idle. Process B now begins a giant vacuum. At some point in the middle > > of the vacuum, A ends the transaction. Are you saying that B's > > GlobalVisTest never really notices that this has happened? > > That's my understanding, yes. That is, vistest is approximately the > same thing as OldestXmin anyway. At least for now. Exactly. Something has to cause this backend to update its view of the horizon. At the end of index vacuuming, GetOldestNonRemovableTransactionId() will explicitly ComputeXidHorizons() which will update our backend's GlobalVisStates. Otherwise, if our backend's RecentXmin is updated, by taking a new snapshot, then we may update our GlobalVisStates. See GlobalVisTestShouldUpdate() for the conditions under which we would update our GlobalVisStates during the normal visibility checks happening during pruning. Vacuum used to open indexes after calculating horizons before starting its first pass. This led to a recomputation of the horizon. But, in master, there aren't many obvious places where such a thing would be happening. - Melanie