From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, "Todd A(dot) Cook" <tcook(at)blackducksoftware(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in an infinite loop |
Date: | 2018-01-29 18:30:49 |
Message-ID: | 20180129183049.xqoejgs52x37xnyr@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 2018-01-29 13:25:35 -0500, Tom Lane wrote:
> The first 2 seem OK to me by eyeball, though I've not done performance
> testing.
Thanks for the look!
> > The third patch is a version of the random IV discussed in this
> > thread. I do think we want to add usage of the extended hash functions,
> > as prototyped by Tomas, as that actually helps to fix issues with actual
> > hash conflicts. But we additionally need a fallback path for types
> > without extended hashtables, and the random IV is a good idea
> > nonetheless. There's no ABI difference in my patch, so I think this is
> > actually something we could backpatch. But I don't think it's urgent, so
> > I'm not planning to do that for 10.2. The one thing that could confuse
> > people is that it can lead to output order changes from run to run - I
> > think that's actually good, nobody should rely on hashagg etc output
> > being stable, but it might be a bit much in a stable release?
>
> 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.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-01-29 18:31:18 | Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in an infinite loop |
Previous Message | Tom Lane | 2018-01-29 18:29:40 | Re: BUG #14932: SELECT DISTINCT val FROM table gets stuck in an infinite loop |