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
