Tom Lane wrote:
> Alvaro Herrera <> 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

Álvaro Herrera      
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to