Re: 9.2rc1 produces incorrect results

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.

In response to

Browse pgsql-hackers by date

  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