Michael Paquier writes:
> On Tue, Sep 9, 2014 at 10:25 PM, Tom Lane wrote:
>> The reason for the assert is that there should never be an OR directly
>> underneath an OR in the planner after eval_const_expressions has flattened
>> such cases. Evidently commit f343a88 failed to preserve AND/OR fla
On Tue, Sep 9, 2014 at 10:25 PM, Tom Lane wrote:
> Michael Paquier writes:
>> The logic for nested OR is correct by reading it, hence why not simply
>> removing the assertion failing? The attached patch 1 does so.
>
> The reason for the assert is that there should never be an OR directly
> undern
Michael Paquier writes:
> The logic for nested OR is correct by reading it, hence why not simply
> removing the assertion failing? The attached patch 1 does so.
The reason for the assert is that there should never be an OR directly
underneath an OR in the planner after eval_const_expressions has
On Tue, Sep 9, 2014 at 2:43 PM, Michael Paquier
wrote:
> Some bisecting is showing as well that the commit at the origin of the
> regression is f343a88.
The failure is caused by an assertion not happy since this commit:
frame #4: 0x000101d20670
postgres`generate_bitmap_or_paths(root=0x
On Tue, Sep 9, 2014 at 6:36 AM, wrote:
> What other information should I provide? We have the machine available if
> necessary.
This can be reproduced without especially LEFT OUTER JOIN, and system
crashes as long as index path is taken in planner, and that WHERE
clause uses a given combination o
li...@benjamindsmith.com writes:
> Using the 9.4 Beta RPMs on CentOS 6.X/64, we're experiencing a reproducible
> crash when running a query with a left outer join, partially collapsed.
The test case crashes as described for me. Will take a look tomorrow.
Thanks for the report!
I think this is the first time I've ever reported a PG crash, which is notable
since I've been using PG for over 10 years. ;)
Using the 9.4 Beta RPMs on CentOS 6.X/64, we're experiencing a reproducible
crash when running a query with a left outer join, partially collapsed.
TRAP: FailedAsserti