Re: pgsql: Fix some issues with step generation in partition pruning.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Etsuro Fujita <efujita(at)postgresql(dot)org>, pgsql-committers <pgsql-committers(at)lists(dot)postgresql(dot)org>
Subject: Re: pgsql: Fix some issues with step generation in partition pruning.
Date: 2020-08-01 18:16:30
Message-ID: 1934344.1596305790@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> writes:
> On Sat, Aug 1, 2020 at 11:13 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Sure looks that way, doesn't it? I'm just now working to reproduce
>> on gaur's host and poke into it with a debugger. More news in an
>> hour or two (it's slow :-().

> Thanks for that!

I've concluded that this is probably a compiler bug. It doesn't fail
at optimization level -O0 or -O2, only -O1; and trying to step through
gen_partprune_steps_internal() suggests that the part_scheme local
variable is changing value, which it surely should not. Since gaur
is running an ancient gcc version, and -O1 is doubtless a pretty
under-tested optimization level, bugs there are not so surprising.

There wasn't any amazingly good reason to be using -O1 for gaur,
so I've switched the animal to use -O2. I expect it'll go back
to green in a few hours.

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2020-08-01 21:12:59 pgsql: Invent "amadjustmembers" AM method for validating opclass member
Previous Message Etsuro Fujita 2020-08-01 16:31:11 Re: pgsql: Fix some issues with step generation in partition pruning.