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: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Melanie Plageman <melanieplageman@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-22T15:54:36Z
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

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> I think it's a bad idea to require buildfarm owners to edit their config
> files as we add tests that depend on PG_TEST_EXTRA.  AFAIR we invented
> that setting so that tests that had security implications could be made
> opt-in instead of opt-out; I think this was a sensible thing to do, to
> avoid possibly compromising the machines in some way.  But I think these
> new tests have a different problem, so we shouldn't use the same
> mechanism.

That's my feeling also.

> What about some brainstorming to improve this?

> For example: have something in the tree that lets committers opt some
> tests out from specific BF machines without having to poke at the BF
> machines.  I imagine two files: one that carries tags for buildfarm
> members, something like the /etc/groups file,

I'd turn it around, and provide some way for buildfarm owners to
say "this machine is slow".  Maybe make the tests respond to the
presence of an environment variable PG_TEST_SKIP_SLOW, or some
such thing.  That particular solution would require no new
infrastructure (such as a new buildfarm client release); it'd
only require editing the config files of affected animals.

			regards, tom lane