| 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-09-29 14:06:34 |
| Message-ID: | 11520.1411999594@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:
> On Sat, Sep 27, 2014 at 1:57 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> We could probably hack solutions to these problems without changing the
>> AppendRelInfo data structures, but I'm wondering if it wouldn't be a good
>> idea to redefine them or at least add more fields to make it easier to
>> work with multi-level appendrel ancestry.
> Hm. Something like oldest_parent_reltype and oldest_parent_relid when
> defining it? IMHO it would be nice to avoid simple hacks if possible but is
> changing AppendRelInfo really something back-patchable at this point?
It seems unlikely that any extensions are creating these structs for
themselves. So I think we could safely add fields at the end in back
branches. We've done that before in other planner structs.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2014-09-29 14:42:01 | Re: pg_dump -Fd fails to detect ENOSPC |
| Previous Message | Jov | 2014-09-29 09:22:46 | Re: BUG #11517: the pg_stat_replication.sync_stat show sync when synchronous_commit is set to be off |