Tom Lane wrote: > Alvaro Herrera <alvhe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
