Hi!
On Sun, Apr 14, 2019 at 11:00 PM Piotr Stefaniak
<postgres@piotr-stefaniak.me> 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