Horton

Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>, Melanie Plageman <melanieplageman@gmail.com>, Peter Geoghegan <pg@bowt.ie>, Heikki Linnakangas <hlinnaka@iki.fi>, Pg Hackers <pgsql-hackers@postgresql.org>, Noah Misch <noah@leadboat.com>
Date: 2024-07-23T00:37:14Z
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 →

  1. Test that vacuum removes tuples older than OldestXmin

  2. Lower minimum maintenance_work_mem to 64kB

  3. Add accidentally omitted test to meson build file

  4. Use DELETE instead of UPDATE to speed up vacuum test

  5. Revert "Test that vacuum removes tuples older than OldestXmin"

  6. Ensure vacuum removes all visibly dead tuples older than OldestXmin

Michael Paquier <michael@paquier.xyz> writes:
> Sawada-san and John are the two ones in the best position to answer
> that.  I'm not sure either how to force a second index pass, either.

Yeah, I think we've established that having some way to force that,
without using a huge test case, would be really desirable.  Maybe
just provide a way to put an artificial limit on how many tuples
processed per pass?

(And no, I wasn't trying to rag on Melanie.  My point here is that
we've failed to design-in easy testability of this code path, and
that's surely not her fault.)

			regards, tom lane