vacuumlazy: Modernize count_nondeletable_pages

From: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Melanie Plageman <melanieplageman(at)gmail(dot)com>
Subject: vacuumlazy: Modernize count_nondeletable_pages
Date: 2025-06-27 11:34:35
Message-ID: CAEze2WiCTd_m_cfR+g4uncoN7vYMUA-CheptKi-RhQYS7kzr9A@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Recently I had to debug an issue with VACUUM's truncate stage taking
an AE lock for a long time, which caused an unpleasant outage due to
blocked queries on a replica. That, and remembering a thread about
this over at [0] got me looking at the code that truncates the
relation.

After looking at the code, I noticed that it has hand-rolled
prefetching of pages, and in a rather peculiar way. Now that we have
the read_stream.c API it is much more efficient to make use that
system, if only to combine IOs and be able to use async IO handling.

While making that change, I also noticed that the current coding does
not guarantee progress when the relation's AE-lock is heavily
contended and the process takes long enough to get started:
When count_nondeletable_pages exits due to lock contention, then
blockno%32==0. In that case the next iteration will start with that
same blockno, and this may cause the scan to make no progress at all
if the time from INSTR_TIME_SET_CURRENT(starttime) to the first
INSTR_TIME_SET_CURRENT(currenttime) is >20ms; while unlikely this does
seem possible on a system with high load.

Attached is a patch which improves the status quo for 1, and fixes
item 2 by increasing the minimum number of pages processed before
releasing the lock to 31.

Kind regards,

Matthias van de Meent
Databricks
[0] https://postgr.es/m/flat/CANqtF-qDGYhYDcpg3PEeDrXMmuJZJGTAeT0mJx0KrN%2BkVikZig%40mail.gmail.com

Attachment Content-Type Size
v1-0001-vacuumlazy-Use-read-stream-for-truncation-scan.patch application/octet-stream 5.4 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniil Davydov 2025-06-27 11:53:02 Re: Prevent internal error at concurrent CREATE OR REPLACE FUNCTION
Previous Message Dave Cramer 2025-06-27 11:20:38 Re: Correct documentation for protocol version