Re: pgsql: Support partition pruning at execution time

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: Support partition pruning at execution time
Date: 2018-04-09 20:55:21
Message-ID: 18110.1523307321@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> David Rowley wrote:
>> Okay, I've written and attached a fix for this. I'm not 100% certain
>> that this is the cause of the problem on pademelon, but the code does
>> look wrong, so needs to be fixed. Hopefully, it'll make pademelon
>> happy, if not I'll think a bit harder about what might be causing that
>> instability.

> Pushed it just now. Let's see what happens with pademelon now.

I've had pademelon's host running a "make installcheck" loop all day
trying to reproduce the problem. I haven't gotten a bite yet (although
at 15+ minutes per cycle, this isn't a huge number of tests). I think
we were remarkably (un)lucky to see the problem so quickly after the
initial commit, and I'm afraid pademelon isn't going to help us prove
much about whether this was the same issue.

This does remind me quite a bit though of the ongoing saga with the
postgres_fdw test instability. Given the frequency with which that's
failing in the buildfarm, you would not think it's impossible to
reproduce outside the buildfarm, and yet I'm here to tell you that
it's pretty damn hard. I haven't succeeded yet, and that's not for
lack of trying. Could there be something about the buildfarm
environment that makes these sorts of things more likely?

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Alvaro Herrera 2018-04-09 21:58:51 Re: pgsql: Support partition pruning at execution time
Previous Message Tom Lane 2018-04-09 20:46:34 Re: pgsql: Merge catalog/pg_foo_fn.h headers back into pg_foo.h headers.

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Dilger 2018-04-09 20:55:29 Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
Previous Message Tom Lane 2018-04-09 20:46:34 Re: pgsql: Merge catalog/pg_foo_fn.h headers back into pg_foo.h headers.