Horton

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

John Naylor <johncnaylorls@gmail.com>

View thread
From: John Naylor <johncnaylorls@gmail.com>
To: Melanie Plageman <melanieplageman@gmail.com>
Cc: Peter Geoghegan <pg@bowt.ie>, Pg Hackers <pgsql-hackers@postgresql.org>, Andres Freund <andres@anarazel.de>, Noah Misch <noah@leadboat.com>
Date: 2025-06-18T04:33: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

On Wed, Jun 18, 2025 at 8:05 AM Melanie Plageman
<melanieplageman@gmail.com> wrote:

> What's odd is that I'm seeing now that I need at least 8000 tuples to
> get > 1 pass of index vacuuming locally with a 64-bit assert build --
> which is more than you are reporting and more than I remember having
> needed for 64-bit builds when I tested this last year with your patch
> applied.
>
> What's even odder is that I tested on a 32-bit build as well (
> -Dc_args='-m32' -Dc_link_args='-m32' --auto-features=disabled) and it
> doesn't require any more than 8000 tuples to get > 1 pass of index
> vacuuming.
>
> So, currently, on both 32 and 64 bit builds and nrows == 8000, I get 2
> passes of index vacuuming.
>
> I can't tell what I'm doing wrong. Could you give your full build
> details?

Here's what numbers I'm looking at as well:

*** normal
meson options: -Dcassert=true -Ddebug=true -Dc_args='-Og'
-Dc_args='-fno-omit-frame-pointer'

$ meson test -q --print-errorlogs --suite setup && meson test -q
--print-errorlogs recovery/048_vacuum_horizon_floor

$ grep finished
build-debug/testrun/recovery/048_vacuum_horizon_floor/log/048_vacuum_horizon_floor_primary.log

2025-06-18 10:08:19.072 +07 [5730] 048_vacuum_horizon_floor.pl INFO:
finished vacuuming "test_db.public.vac_horizon_floor_table": index
scans: 12

*** 32-bit
meson options: -Dcassert=true -Ddebug=true --auto-features=disabled
-Dtap_tests=enabled -Dc_args='-m32' -Dc_link_args='-m32'

$ meson test -q --print-errorlogs --suite setup && meson test -q
--print-errorlogs recovery/048_vacuum_horizon_floor

$ grep finished
build-debug32/testrun/recovery/048_vacuum_horizon_floor/log/048_vacuum_horizon_floor_primary.log

2025-06-18 10:27:43.088 +07 [22796] 048_vacuum_horizon_floor.pl INFO:
finished vacuuming "test_db.public.vac_horizon_floor_table": index
scans: 5

> There's no chance that you made a change to the TIDStore that
> would make it possible for any configuration to have the same size
> TIDStore on a 32 and 64 bit build, right?

Not yet.

-- 
John Naylor
Amazon Web Services