Horton

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

Andres Freund <andres@anarazel.de>

View thread
From: Andres Freund <andres@anarazel.de>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Melanie Plageman <melanieplageman@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>, Pg Hackers <pgsql-hackers@postgresql.org>, Noah Misch <noah@leadboat.com>
Date: 2024-07-22T18:13:32Z
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

On 2024-07-22 12:00:51 -0400, Peter Geoghegan wrote:
> On Mon, Jul 22, 2024 at 11:49 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > >> Andres has suggested in the past that we allow maintenance_work_mem be
> > >> set to a lower value or introduce some kind of development GUC so that
> > >> we can more easily test multiple pass index vacuuming. Do you think
> > >> this would be worth it?
> >
> > > No, I don't.
> >
> > I don't see why that's not a good idea.
> 
> I don't think that it's worth going to that trouble. Testing multiple
> passes isn't hard -- not in any real practical sense.

It's hard by now (i.e. 17+) because you need substantial amounts of rows to be
able to trigger it which makes it a hard fight to introduce. And the cost of
setting the GUC limit lower is essentially zero.

What's the point of having such a high lower limit?

Greetings,

Andres Freund