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: Peter Geoghegan <pg@bowt.ie>
Cc: Melanie Plageman <melanieplageman@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>, Pg Hackers <pgsql-hackers@postgresql.org>, Andres Freund <andres@anarazel.de>, Noah Misch <noah@leadboat.com>
Date: 2024-07-21T21:04:42Z
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

Peter Geoghegan <pg@bowt.ie> writes:
> On Sun, Jul 21, 2024 at 12:51 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.

> Can't we just move it to PG_TEST_EXTRA? Alongside the existing
> "xid_wraparound" test?

Perhaps.  xid_wraparound seems entirely too slow for what it's
testing as well, if you ask me, and there's a concurrent thread
about that test causing problems too.

> There will always be a small number of extremely slow buildfarm
> animals. Optimizing for things like Raspberry pi animals with SD cards
> just doesn't seem like a good use of developer time. I really care
> about keeping the tests fast, but only on platforms that hackers
> actually use for their development work.

I find this argument completely disingenuous.  If a test is slow
enough to cause timeout failures on slower machines, then it's also
eating a disproportionate number of cycles in every other check-world
run --- many of which have humans waiting for them to finish.  Caring
about the runtime of test cases is good for future-you not just
obsolete buildfarm animals.

I note also that the PG_TEST_EXTRA approach has caused xid_wraparound
to get next-to-zero buildfarm coverage.  If that test is actually
capable of revealing problems, we're unlikely to find out under the
status quo.

			regards, tom lane