Re: 10.1: hash index size exploding on vacuum full analyze - Mailing list pgsql-hackers

From Teodor Sigaev
Subject Re: 10.1: hash index size exploding on vacuum full analyze
Date
Msg-id 4356d9d4-e702-985f-eeda-de0b7e4a6b58@sigaev.ru
Whole thread Raw
In response to Re: 10.1: hash index size exploding on vacuum full analyze  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
thank you, pushed

Amit Kapila wrote:
> On Tue, Dec 26, 2017 at 9:48 PM, Teodor Sigaev <teodor@sigaev.ru> wrote:
>>> Initially, I have also thought of doing it in swap_relation_files, but
>>> we don't have stats values there.  We might be able to pass it, but
>>> not sure if there is any need for same.  As far as Toast table's case
>>> is concerned, I don't see the problem because we are copying the data
>>> row-by-row only for heap where the value of num_tuples and num_pages
>>> could be different.  See  copy_heap_data.
>>
>>
>> Ok, agree. AP (sorry, I don't see your name), could your check that patch
>> fixes your issue?
>>
>> Nevertheless, I'm going to push this patch in any case and, suppose, it
>> should be backpatched to version 10 too, although the bug is not about data
>> loss or any corruption. But patch looks rather  straightforward and has low
>> risk of some new bugs.
>>
> 
> Ideally, we can backpatch this patch to prior versions as well, but I
> think users will see this problem in v10 onwards (as hash indexes are
> primarily getting used from v10), so it seems okay to backpatch till
> 10.  In future, if we see any other symptom in prior branches, then we
> can always backpatch it.
> 
> 

-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
                                                    WWW: http://www.sigaev.ru/


pgsql-hackers by date:

Previous
From: Devrim Gündüz
Date:
Subject: Re: pgcrypto rpm package
Next
From: Konstantin Knizhnik
Date:
Subject: Re: AS OF queries