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
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. |