vacuumlazy: Modernize count_nondeletable_pages
От | Matthias van de Meent |
---|---|
Тема | vacuumlazy: Modernize count_nondeletable_pages |
Дата | |
Msg-id | CAEze2WiCTd_m_cfR+g4uncoN7vYMUA-CheptKi-RhQYS7kzr9A@mail.gmail.com обсуждение исходный текст |
Ответы |
Re: vacuumlazy: Modernize count_nondeletable_pages
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: