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

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Nelson Page <npage(at)dynamicsignal(dot)com>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #11457: The below query crashes 9.3.5, but not 9.3.4
Date: 2014-10-01 07:52:43
Message-ID: CAB7nPqS3xsWezFEnyQPNajUVkrTGyKjsP3rqAETDvsw0SyDCCQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, Oct 1, 2014 at 2:43 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Accordingly, I propose a patch more like the attached. This doesn't
> try to change the data structures, but it does take the viewpoint that
> all current callers of find_childrel_appendrelinfo() need to be fixed
> to explicitly consider multiple levels of parent appendrels.
>
This approach is far more solid than my previous stuff and makes the
approach I took really brittle... Looking at your code, I am wondering if
it would not be safer to add some assertions in find_childrel_top_parent
and find_childrel_parents, something like a check on RELOPT_BASEREL for
rel->reloptkind before returning a result. Er, those new functions should
always finishing by scanning a base rel, right?

Btw, this code will need minor adjustments for REL9_2_STABLE and
REL9_3_STABLE. Is a backpatch down to 9.1 to be considered?
--
Michael

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Ashish Gupta 2014-10-01 11:36:38 I am not able to backup local database.
Previous Message Tom Lane 2014-10-01 05:43:28 Re: BUG #11457: The below query crashes 9.3.5, but not 9.3.4