Re: Failures with installcheck and low work_mem value in 13~

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
Subject: Re: Failures with installcheck and low work_mem value in 13~
Date: 2020-06-25 19:15:54
Message-ID: CAH2-WznMWxZxRfZx__AmnHbQr3-0-2Xv-CqaQCDhbOpAXU2HAQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jun 19, 2020 at 7:48 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> We cared about such plan stability that in the past FWIW, see for
> example c588df9 as work_mem is a setting that people like to change.
> Why should this be different? work_mem is a popular configuration
> setting.

The RMT met today. We determined that it wasn't worth adjusting this
test to pass with non-standard work_mem values.

"make installcheck" also fails with lower random_page_cost settings.
There doesn't seem to be any reason to permit a non-standard setting
to cause installcheck to fail elsewhere, while not tolerating the same
issue here, with work_mem.

Thanks
--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2020-06-25 19:24:42 Re: Default setting for enable_hashagg_disk
Previous Message Robert Haas 2020-06-25 19:06:22 Re: Why forbid "INSERT INTO t () VALUES ();"