On 2013-08-30 18:55:53 -0400, Tom Lane wrote:
> Andres Freund <and...@2ndquadrant.com> writes:
> > On 2013-08-30 23:05:25 +0200, Andres Freund wrote:
> >> ExecReScanMergeAppend resets ms_initialized, but doesn't clear the
> >> binaryheap. Thus no new elements fit.
>
> > Ok, patch for that attached.
>
> I think the comments need a bit of copy-editing, but looks good otherwise.
> Will fix and commit.
Thanks.
> > Should we add
> > SELECT (SELECT g.i FROM ((SELECT random()::int ORDER BY 1 OFFSET 0) UNION
> > ALL (SELECT random()::int ORDER BY 1 OFFSET 0)) f(i) ORDER BY f.i LIMIT 1)
> > FROM generate_series(1, 10) g(i);
> > as a regression test? I slightly on the "no" side...
>
> Not sure. It's pretty disturbing that this wasn't caught earlier;
> it seems to me that means there's no regression coverage that hits
> ExecReScanMergeAppend. However, I don't much like this specific test case
> because it seems like hitting the bug could depend on what series of
> random values you get.
Hm, that should be fixable. How about:
SELECT
-- correlated subquery, with dependency on outer query, to force rescans
-- which will be planned as a merge-append.
(SELECT g.i FROM (
(SELECT * FROM generate_series(1, 2) ORDER BY 1)
UNION ALL
(SELECT * FROM generate_series(1, 2) ORDER BY 1)
) f(i)
ORDER BY f.i LIMIT 1)
FROM generate_series(1, 3) g(i);
I couldn't find a simpler testcase within some minutes...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
