Re: installcheck failing on psql_crosstab

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: installcheck failing on psql_crosstab
Date: 2016-06-06 14:13:24
Message-ID: 6168.1465222404@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)2ndquadrant(dot)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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-06-06 14:15:28 Re: Reviewing freeze map code
Previous Message Alvaro Herrera 2016-06-06 14:06:10 Re: installcheck failing on psql_crosstab