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
