Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
От | Peter Geoghegan |
---|---|
Тема | Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations |
Дата | |
Msg-id | CAH2-Wz=DHb2hXGqcvuVyy0qC88VcYoaNjy2FFtb-xjQMOZTQqw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
|
Список | pgsql-hackers |
On Fri, Feb 18, 2022 at 2:11 PM Andres Freund <andres@anarazel.de> wrote: > I think it'd be good to add a few isolationtest cases for the > can't-get-cleanup-lock paths. I think it shouldn't be hard using cursors. The > slightly harder part is verifying that VACUUM did something reasonable, but > that still should be doable? We could even just extend existing, related tests, from vacuum-reltuples.spec. Another testing strategy occurs to me: we could stress-test the implementation by simulating an environment where the no-cleanup-lock path is hit an unusually large number of times, possibly a fixed percentage of the time (like 1%, 5%), say by making vacuumlazy.c's ConditionalLockBufferForCleanup() call return false randomly. Now that we have lazy_scan_noprune for the no-cleanup-lock path (which is as similar to the regular lazy_scan_prune path as possible), I wouldn't expect this ConditionalLockBufferForCleanup() testing gizmo to be too disruptive. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: