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: Tom Lane <tgl@sss.pgh.pa.us>
Cc: 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-22T16:47:45Z
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

Hi,

On 2024-07-21 12:51:51 -0400, Tom Lane wrote:
> Melanie Plageman <melanieplageman@gmail.com> writes:
> > When I run it on my machine with some added logging, the space taken
> > by dead items is about 330 kB more than maintenance_work_mem (which is
> > set to 1 MB). I could roughly double the excess by increasing the
> > number of inserted tuples from 400000 to 600000. I'll do this.

> mamba, gull, and mereswine are 32-bit machines, which aside from
> being old and slow suffer an immediate 2x size-of-test penalty:

I think what we ought to do here is to lower the lower limit for memory usage
for vacuum. With the new state in 17+ it basically has become impossible to
test multi-pass vacuums in a way that won't get your test thrown out - that's
bad.


> I do not think the answer to this is to nag the respective animal owners to
> raise PG_TEST_TIMEOUT_DEFAULT.  IMV this test is simply not worth the cycles
> it takes, at least not for these machines.

This specific area of the code has a *long* history of bugs, I'd be very loath
to give up testing.

Greetings,

Andres Freund