Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in an infinite loop

Andres Freund <andres(at)anarazel(dot)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