Re: BUG #11457: The below query crashes 9.3.5, but not 9.3.4

As mentioned in the original title, we cannot reproduce this crash in 9.3.4=
, but can in 9.3.5.  So our particular crash does not go back to 9.1 (unles=
s the 9.1 you mention is some other context maybe?)

Regards,
Nelson

-----Original Message-----
From: Michael Paquier [mailto:michael.paquier@gmail.com]=20
Sent: Friday, September 26, 2014 12:29 AM
To: Tom Lane
Cc: Alvaro Herrera; Nelson Page; pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #11457: The below query crashes 9.3.5, but not 9.3.=
4

On Tue, Sep 23, 2014 at 1:04 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Hm, probably the same thing then as
> http://www.postgresql.org/message-id/2326379.AOuSqtNClj@klinga.prans.o
> rg
Yes, both cases are similar, with the use of two levels of relations introd=
ucing.

> I was poking at that one earlier this evening.  The immediate fix is=20
> clear enough (generate_implied_equalities_for_column should be=20
> considering "grandparent" appendrels), but I'm not sure yet whether we=20
> need to change the logic in generate_join_implied_equalities.

I could reproduce it as well with the scripts previously sent, and this reg=
ression has been introduced by a2db7b7 on REL9_3_STABLE, backpatched from a=
87c729 on master. Hence I imagine that this is reproducible down to 9.1. Al=
so, looking at the code the additions in add_child_rel_equivalences to bypa=
ss the case where parent is not mentioned in equivclass seems to be the roo=
t cause of the regression.

I have not come up yet with a patch fixing this issue though without introd=
ucing regressions in other code paths... But I have been able at least to c=
ome up with the attached minimalistic example to reproduce the problem. Som=
ething similar to that could be part of a regression test to add in the fin=
al patch.
Regards,
--
Michael