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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
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 14:22:01
Message-ID: 9603.1412173321@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
> This approach is far more solid than my previous stuff and makes the
> approach I took really brittle...

Hey, the idea to add a field was mine, so don't beat yourself up about
it :-). Sometimes it takes working out an idea to realize it's bad.

> 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?

Yeah, not a bad idea.

> 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?

The bugs we're working on here are definitely demonstrable back to 9.2.
I'm not sure about 9.1 yet; but considering that a87c72915 had to get
back-patched as far as 9.1, there may well be some manifestations of
these problems visible in 9.1. (The new regression test that I wrote
doesn't seem to show any big problems there, but maybe I'm just short
a case or two.)

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message armandogutheil 2014-10-01 14:52:25 BUG #11548: Date insert error
Previous Message Ashish Gupta 2014-10-01 11:36:38 I am not able to backup local database.