Re: installcheck failing on psql_crosstab
От | Alvaro Herrera |
---|---|
Тема | Re: installcheck failing on psql_crosstab |
Дата | |
Msg-id | 20160606142001.GA388118@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: installcheck failing on psql_crosstab (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: installcheck failing on psql_crosstab
|
Список | pgsql-hackers |
Tom Lane wrote: > Alvaro Herrera <alvherre@2ndquadrant.com> writes: > > Michael Paquier wrote: > >> I know that we guarantee that make installcheck may not work on many > >> target servers as a lot of tests are very GUC-sensitive, but this > >> looks a bit oversensitive to me, especially knowing that it is the > >> only diff generated by the whole test suite. > >> Don't you think that those tests could be made more portable? > > > Not sure about that. I think the only way to change this would be to > > remove those particular tests completely, and I don't think that's a > > good tradeoff. If somebody can show a way to avoid the problem without > > removing those tests for multiline functionality, I'm all ears. > > Presumably what is happening is that the planner is switching from hash > to sort aggregation. We could force the plan choice via enable_hashagg, > which seems OK from the standpoint that this is only meant to test psql > not the backend. However, I'm dubious of the entire project. I think > if you push the value of work_mem a bit further in either direction, > you will find other tests falling over. I'm not excited about changing > this one just because it's currently the first to fail. I can't imagine that the server is avoiding hash aggregation on a 1MB work_mem limit for data that's a few dozen of bytes. Is it really doing that? -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: