Re: Analyzing bug 8049

Поиск
Список
Период
Сортировка
От Jov
Тема Re: Analyzing bug 8049
Дата
Msg-id CADyrUxNMndtOW4vjTjGZsvsrW_XLY5UT1TYoKHH83astHrFW4Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Analyzing bug 8049  ("Dickson S. Guedes" <listas@guedesoft.net>)
Список pgsql-hackers
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@guedesoft.net>
Em Sex, 2013-04-12 às 10:58 -0400, Tom Lane escreveu:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Thu, Apr 11, 2013 at 1:25 PM, Tom Lane <tgl@sss.pgh.pa.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@guedesoft.net - skype: guediz
http://guedesoft.net - http://www.postgresql.org.br
http://www.rnp.br/keyserver/pks/lookup?search=0x8F3E3C06D428D10A



--
Jov

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Vik Fearing
Дата:
Сообщение: Re: 9.3 Beta1 status report
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Redundancy in comment within lock.c