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.
diff --git a/src/backend/access/nbtree/nbtree.c b/src/backend/access/nbtree/nbtree.c
index 7370379c6..caf84de1d 100644
--- a/src/backend/access/nbtree/nbtree.c
+++ b/src/backend/access/nbtree/nbtree.c
@@ -835,7 +835,9 @@ _bt_vacuum_needs_cleanup(IndexVacuumInfo *info)
prev_num_heap_tuples = metad->btm_last_cleanup_num_heap_tuples;
if (cleanup_scale_factor <= 0 ||
- prev_num_heap_tuples < 0 ||
+ prev_num_heap_tuples < 0)
+ result = true;
+ else if (prev_num_heap_tuples != 0 &&
(info->num_heap_tuples - prev_num_heap_tuples) /
prev_num_heap_tuples >= cleanup_scale_factor)
result = true;
