Re: GiST VACUUM - Mailing list pgsql-hackers

From Andrey Borodin
Subject Re: GiST VACUUM
Date
Msg-id 2AF4B7F1-ABCF-4602-8AF8-06EA45191BFC@yandex-team.ru
Whole thread Raw
In response to Re: GiST VACUUM  (Thomas Munro <thomas.munro@enterprisedb.com>)
Responses Re: GiST VACUUM
List pgsql-hackers
Hi!

Thank you!

> 29 июля 2018 г., в 14:04, Thomas Munro <thomas.munro@enterprisedb.com> написал(а):
>
> On Tue, Jul 24, 2018 at 6:04 AM, Andrey Borodin <x4mmm@yandex-team.ru> wrote:
>>> 21 июля 2018 г., в 17:11, Andrey Borodin <x4mmm@yandex-team.ru> написал(а):
>>> <0001-Physical-GiST-scan-in-VACUUM-v13.patch>
>>
>> Just in case, here's second part of patch series with actual page deletion.
>
> Hi Andrey,
>
> Cfbot says:
>
> https://ci.appveyor.com/project/postgresql-cfbot/postgresql/build/1.0.7146
>
> That's because you declared a new variable after some other
> statements.  You can't do that in old school C89.
Yep, mismerged patch steps and created misplaced declaration

> https://travis-ci.org/postgresql-cfbot/postgresql/builds/409401951
>
> That segfaulted here:
>
> #0 0x00000000004ab620 in setinternal (state=<optimized out>,
> state=<optimized out>, blkno=368) at gistvacuum.c:44
> 44 state->internalPagesMap[blkno / 8] |= 1 << (blkno % 8);
>
> internalPagesMap was NULL, or pointed to memory that was too small and
> happened to be near an unmapped region (unlikely?), or was some other
> corrupted address?
Yes, there was conditionally uninitialized variable mapNumPages. I do not know why it didn't trigger failure last time,
butnow it was reproduced on my machine reliably. 

Fixed both problems. PFA v14.

Best regards, Andrey Borodin.

Attachment

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: [PATCH] Improve geometric types
Next
From: Tomas Vondra
Date:
Subject: Re: [PATCH] Improve geometric types