Aliaksandr Kalenik <akalenik@kontur.io> writes:
> I was investigating a leak reported in the PostGIS issues tracker [1] which
> led me to the Postgres side where the problem really is. The leak is
> reproducible with query from original ticket [1]:
> ...
> The leak is only noticeable when index scan with reorder happens as part of
> subquery plan which is explained by the fact that heap tuples cloned in
> reorderqueue_push are not freed during flush of reorder queue in
> ExecReScanIndex.
Actually, that code has got worse problems than that. I tried to improve
our regression tests to exercise that code path, as attached. What I got
was
+SELECT point(x,x), (SELECT circle_center(f1) FROM gcircle_tbl ORDER BY f1 <-> p
oint(x,x) LIMIT 1) as c FROM generate_series(0,1000,1) x;
+ERROR: index returned tuples in wrong order
(The error doesn't always appear depending on what generate_series
parameters you use, but it seems to show up consistently with
a step of 1 and a limit of 1000 or more.)
Fixing this is well beyond my knowledge of that code, so I'm punting
it to the original authors.
regards, tom lane
diff --git a/src/test/regress/sql/create_index.sql b/src/test/regress/sql/create_index.sql
index 8b353be16e..0b60caabe4 100644
--- a/src/test/regress/sql/create_index.sql
+++ b/src/test/regress/sql/create_index.sql
@@ -255,6 +255,10 @@ EXPLAIN (COSTS OFF)
SELECT circle_center(f1), round(radius(f1)) as radius FROM gcircle_tbl ORDER BY f1 <-> '(200,300)'::point LIMIT 10;
SELECT circle_center(f1), round(radius(f1)) as radius FROM gcircle_tbl ORDER BY f1 <-> '(200,300)'::point LIMIT 10;
+EXPLAIN (COSTS OFF)
+SELECT point(x,x), (SELECT circle_center(f1) FROM gcircle_tbl ORDER BY f1 <-> point(x,x) LIMIT 1) as c FROM
generate_series(0,1000,1)x;
+SELECT point(x,x), (SELECT circle_center(f1) FROM gcircle_tbl ORDER BY f1 <-> point(x,x) LIMIT 1) as c FROM
generate_series(0,1000,1)x;
+
-- Now check the results from bitmap indexscan
SET enable_seqscan = OFF;
SET enable_indexscan = OFF;
