From: | Vik Reykja <vikreykja(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: 9.2rc1 produces incorrect results |
Date: | 2012-09-05 07:50:44 |
Message-ID: | CALDgxVuLr6ZVUKupFooQELCV6m8mSGKvR2jCJazgKbywcxfxUQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Sep 5, 2012 at 6:09 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I wrote:
> > I think probably the best fix is to rejigger things so that Params
> > assigned by different executions of SS_replace_correlation_vars and
> > createplan.c can't share PARAM_EXEC numbers. This will result in
> > rather larger ecxt_param_exec_vals arrays at runtime, but the array
> > entries aren't very large, so I don't think it'll matter.
>
> Attached is a draft patch against HEAD for this. I think it makes the
> planner's handling of outer-level Params far less squishy than it's ever
> been, but it is rather a large change. Not sure whether to risk pushing
> it into 9.2 right now, or wait till after we cut 9.2.0 ... thoughts?
>
I am not in a position to know what's best for the project but my company
can't upgrade (from 9.0) until this is fixed. We'll wait for 9.2.1 if we
have to. After all, we skipped 9.1.
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2012-09-05 08:03:47 | Re: Cascading replication and recovery_target_timeline='latest' |
Previous Message | Amit Kapila | 2012-09-05 05:31:23 | Re: Proof of concept: standalone backend with full FE/BE protocol |