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
v1-0001-vacuumlazy-Use-read-stream-for-truncation-scan.patch
Description: Binary data
