From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Todd A. Cook <tcook@blackducksoftware.com>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: PostgreSQL Bugs <pgsql-bugs@postgresql.org>
Subject: Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in an infinite loop
Date: Mon, 29 Jan 2018 13:45:10 -0500
Message-ID: <6340.1517251510@sss.pgh.pa.us> (raw)
In-Reply-To: <20180129183049.xqoejgs52x37xnyr@alap3.anarazel.de>
References: <219b37b2-d740-d04a-203a-49ae422028f7@blackducksoftware.com>
<c15378b3-d4aa-a5c0-5538-dd52904dcbc6@2ndquadrant.com>
<1773c302-2fb1-749f-8ccc-62b23617c5ac@blackducksoftware.com>
<25629.1512580464@sss.pgh.pa.us>
<20171206171923.dg7phzfh7nb4lou3@alap3.anarazel.de>
<7de4b2d6-b119-7d15-04d8-4c0fcb29cbc3@2ndquadrant.com>
<20180126234537.dyu6jwnqz7snpq7n@alap3.anarazel.de>
<14184.1517010515@sss.pgh.pa.us>
<20180129010213.rt3nu73ilff756f6@alap3.anarazel.de>
<5429.1517250335@sss.pgh.pa.us>
<20180129183049.xqoejgs52x37xnyr@alap3.anarazel.de>
Andres Freund <andres@anarazel.de> writes:
> On 2018-01-29 13:25:35 -0500, Tom Lane wrote:
>> I disagree: people should reasonably expect the same query and same
>> data and same plan to give consistent results. When we stuck in the
>> "synchronous seqscans" feature, which broke that property, we were very
>> quickly forced by user complaints to provide a way to shut it off.
>> I'm also concerned that we'd have to lobotomize a bunch of regression
>> test cases to ensure stable results there.
> I don't think the cases really compare. For one there's no "natural
> order" like insertion order for seqscans (in simplistic cases). For
> another hashaggs/joins/whatnot are *already* architecture dependent, so
> there's ORDER BYs for pretty much everything already - I needed to add a
> single ORDER BY to make things stable over ~50 regression runs.
As developers who see test results from a variety of architectures,
we're aware that hash ops don't give stable results across machines.
Most end users aren't going to know or care about that: they're running
on one architecture and up to now they've gotten stable results from
hash ops. I think we *will* get pushback if we change that.
Also, the fact that you needed one more ORDER BY in testing on a
single machine is already proof of my worry about the regression
tests, and it'll only get worse when testing across a variety
of machines.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, andres@anarazel.de, tomas.vondra@2ndquadrant.com, tcook@blackducksoftware.com, thomas.munro@enterprisedb.com
Subject: Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in an infinite loop
In-Reply-To: <6340.1517251510@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox