Re: BUG #11457: The below query crashes 9.3.5, but not 9.3.4 - Mailing list pgsql-bugs

From Nelson Page
Subject Re: BUG #11457: The below query crashes 9.3.5, but not 9.3.4
Date
Msg-id 4251b913e1464058b8e08d3e625bede3@BN3PR0401MB1265.namprd04.prod.outlook.com
Whole thread Raw
In response to Re: BUG #11457: The below query crashes 9.3.5, but not 9.3.4  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: BUG #11457: The below query crashes 9.3.5, but not 9.3.4
List pgsql-bugs
Hi Michael,

I've attached the create scripts for those tables.  I'm relatively new to postgresql, so if that's not as helpful as I
thinkit is, let me know what else I can provide. 

Thanks,
Nelson

-----Original Message-----
From: Michael Paquier [mailto:michael.paquier@gmail.com]
Sent: Saturday, September 20, 2014 10:44 AM
To: Nelson Page
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #11457: The below query crashes 9.3.5, but not 9.3.4

On Fri, Sep 19, 2014 at 7:23 PM,  <npage@dynamicsignal.com> wrote:
> SELECT
> [stuff]
>         ) As "GroupBy1"
I tried to come up with a minimum schema close to what is used in your example, aka 7 relations, 6 unioning on an ID
columnwith an extra inner join, and then tried the same query but I could not trigger the crash on master, latest
REL9_3_STABLE(9474c9d) or even 9.3.5. 

Having only a query (on 7 relations btw!) and not a self-contained test-case makes it harder to reproduce a crash.
Couldyou provide at least a minimum schema that triggers the crash so as we could reproduce it more easily? I am
attachingas well the self-contained test case with your query and the minimal schema I could come up with for the
momentjust for reference. 
Regards,
--
Michael

Attachment

pgsql-bugs by date:

Previous
From: rahiyer@gmail.com
Date:
Subject: BUG #11469: Recursive plpython function results in KeyError for next function
Next
From: Alvaro Herrera
Date:
Subject: Re: BUG #11457: The below query crashes 9.3.5, but not 9.3.4