| From: | Piotr Stefaniak <postgres(at)piotr-stefaniak(dot)me> |
|---|---|
| To: | "pgsql-committers(at)lists(dot)postgresql(dot)org" <pgsql-committers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: pgsql: Increase upper limit for vacuum_cleanup_index_scale_factor |
| Date: | 2019-04-14 19:59:46 |
| Message-ID: | DB8PR03MB5931C41F7787A95313F08322F22A0@DB8PR03MB5931.eurprd03.prod.outlook.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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 | Content-Type | Size |
|---|---|---|
| zero-divide-prev_num_heap_tuples.patch | text/x-patch | 633 bytes |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Korotkov | 2019-04-15 02:21:38 | Re: pgsql: Increase upper limit for vacuum_cleanup_index_scale_factor |
| Previous Message | Michael Paquier | 2019-04-14 10:21:15 | Re: pgsql: Switch TAP tests of pg_rewind to use a role with minimal permiss |