From: | Marina Polyakova <m(dot)polyakova(at)postgrespro(dot)ru> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Subject: | Re: master check fails on Windows Server 2008 |
Date: | 2018-02-20 18:15:00 |
Message-ID: | 643f22e371f2a885ebf5936dea0d7e82@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 20-02-2018 3:37, Tom Lane wrote:
> Ah-hah. I can reproduce the described failure if I configure with
> --disable-float8-byval on an otherwise 64-bit machine. It appears that
> the minimum work_mem setting that will allow this query to use a
> hashagg
> plan on such a configuration is about 155kB (which squares with the
> results you show). On the other hand, in a normal 64-bit
> configuration,
> work_mem settings of 160kB or more cause other failures (due to other
> plans switching to hashagg), and on a 32-bit machine I see such
> failures
> with work_mem of 150kB or more. So there's basically no setting of
> work_mem that would make all these tests pass everywhere.
>
> I see several things we could do about this:
>
> 1. Nothing; just say "sorry, we don't promise that the regression tests
> pass with no plan differences on nonstandard configurations". Given
> that
> --disable-float8-byval has hardly any real-world use, there is not a
> lot
> of downside to that.
>
> 2. Decide that --disable-float8-byval, and for that matter
> --disable-float4-byval, have no real-world use at all and take them
> out.
> There was some point in those options back when we cared about binary
> compatibility with version-zero C functions, but now I'm not sure why
> anyone would use them.
>
> 3. Drop that one test case from stats_ext.sql; I'm not sure how much
> additional test value it's actually bringing.
>
> 4. Try to tweak the stats_ext.sql test conditions in some more refined
> way to get the test to pass everywhere. This'd be a lot of work with
> no guarantee of success, so I'm not too excited about it.
Thank you for your explanations! I'll try to do something in this
direction..
> 5. Something else?
>
> regards, tom lane
--
Marina Polyakova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-02-20 18:20:23 | Re: ALTER TABLE ADD COLUMN fast default |
Previous Message | Patrick Krecker | 2018-02-20 18:09:16 | Re: Option to ensure monotonic timestamps |