Re: Analyzing bug 8049

I don't think so. It makes bugs like this hidden,but people will complaint
pg is not that reliable because different stat data can make pg produce
different result for the same query.

mybe we should make the regress test run under all the combination of query
configures (enabale_*) to make sure all the query plan path is correct?

2013/4/12 Dickson S. Guedes <listas(at)guedesoft(dot)net>

> Em Sex, 2013-04-12 às 10:58 -0400, Tom Lane escreveu:
> > Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > > On Thu, Apr 11, 2013 at 1:25 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > >> The plan I'm considering is to get this written and committed to HEAD
> > >> in the next week, so that it can go out in 9.3beta1. After the patch
> > >> has survived a reasonable amount of beta testing, I'd be more
> comfortable
> > >> about back-patching into 9.2.
> >
> > > I'm not very sanguine about the chances that back-patching this won't
> > > provoke any screams of agony ... but I don't have a better idea,
> > > either. Letting queries return wrong answers isn't a superior
> > > solution, for sure.
> >
> > The only alternative I can see is to make a back-patch that just teaches
> > get_eclass_for_sort_expr() to compute valid nullable_relids for the sort
> > expression.
>
>
> In my tests, after ANALYZE _bug_header and _bug_line, the query plan
> changes and query results returns as expected. Is this a chance that
> things isn't too bad?
>
>
> []s
> --
> Dickson S. Guedes
> mail/xmpp: guedes(at)guedesoft(dot)net - skype: guediz
> http://guedesoft.net - http://www.postgresql.org.br
> http://www.rnp.br/keyserver/pks/lookup?search=0x8F3E3C06D428D10A
>

--
Jov
blog: http:amutu.com/blog <http://amutu.com/blog>