Re: BUG #8410: out of binary heap slots

On 2013-08-30 18:55:53 -0400, Tom Lane wrote:
> Andres Freund <andres@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
OFFSET0)) 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