Hi! On Sun, Apr 14, 2019 at 11:00 PM Piotr Stefaniak <[email protected]> wrote: > On 26/06/2018 14.35, Alexander Korotkov wrote: > > Increase upper limit for vacuum_cleanup_index_scale_factor > > > > Upper limits for vacuum_cleanup_index_scale_factor GUC and reloption > > were initially set to 100.0 in 857f9c36. However, after further > > discussion, it appears that some users like to disable B-tree cleanup > > index scan completely (assuming there are no deleted pages). > > > > vacuum_cleanup_index_scale_factor is used barely to protect against > > stalled index statistics. And after detailed consideration it appears > > that risk of stalled index statistics is low. And it would be nice to > > allow advanced users setting higher values of > > vacuum_cleanup_index_scale_factor. So, set upper limit for these > > GUC and reloption to DBL_MAX. > > UB Sanitizer points out that prev_num_heap_tuples is sometimes 0, > leading to division by 0 in > (info->num_heap_tuples - prev_num_heap_tuples) / > prev_num_heap_tuples >= cleanup_scale_factor) > which are currently lines 839-840 in nbtree.c. > > Attaching my idea of a fix.
Thank you for noticing. BTW, I've more trivial idea for fixing this: replace prev_num_heap_tuples < 0 with prev_num_heap_tuples <= 0 If prev_num_heap_tuples == 0, subsequent part of expression isn't evaluated because result is known to be true. And I think it's right to don't skip cleanup when prev_num_heap_tuples == 0. ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
fix-division-by-zero-bt-vacuum-needs-cleanup.patch
Description: Binary data
