Re: pgsql: Increase upper limit for vacuum_cleanup_index_scale_factor - Mailing list pgsql-committers

From Piotr Stefaniak
Subject Re: pgsql: Increase upper limit for vacuum_cleanup_index_scale_factor
Date
Msg-id DB8PR03MB5931C41F7787A95313F08322F22A0@DB8PR03MB5931.eurprd03.prod.outlook.com
Whole thread Raw
In response to pgsql: Increase upper limit for vacuum_cleanup_index_scale_factor  (Alexander Korotkov <akorotkov@postgresql.org>)
Responses Re: pgsql: Increase upper limit for vacuum_cleanup_index_scale_factor  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
List pgsql-committers
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.

Attachment

pgsql-committers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: pgsql: Switch TAP tests of pg_rewind to use a role with minimalpermiss
Next
From: Alexander Korotkov
Date:
Subject: Re: pgsql: Increase upper limit for vacuum_cleanup_index_scale_factor