aboutsummaryrefslogtreecommitdiff
path: root/src/test/regress/sql/gist.sql
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2017-05-04 13:59:13 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2017-05-04 13:59:39 -0400
commit3f074845a8c190b365e68e39e39017ff70330f2a (patch)
treef70c8226f8b404ffa1724c7dc5182c59f47caca3 /src/test/regress/sql/gist.sql
parent20bf7b2b0afcb53608ec37005ee7f831132925d2 (diff)
downloadpostgresql-3f074845a8c190b365e68e39e39017ff70330f2a.tar.gz
postgresql-3f074845a8c190b365e68e39e39017ff70330f2a.zip
Fix pfree-of-already-freed-tuple when rescanning a GiST index-only scan.
GiST's getNextNearest() function attempts to pfree the previously-returned tuple if any (that is, scan->xs_hitup in HEAD, or scan->xs_itup in older branches). However, if we are rescanning a plan node after ending a previous scan early, those tuple pointers could be pointing to garbage, because they would be pointing into the scan's pageDataCxt or queueCxt which has been reset. In a debug build this reliably results in a crash, although I think it might sometimes accidentally fail to fail in production builds. To fix, clear the pointer field anyplace we reset a context it might be pointing into. This may be overkill --- I think probably only the queueCxt case is involved in this bug, so that resetting in gistrescan() would be sufficient --- but dangling pointers are generally bad news, so let's avoid them. Another plausible answer might be to just not bother with the pfree in getNextNearest(). The reconstructed tuples would go away anyway in the context resets, and I'm far from convinced that freeing them a bit earlier really saves anything meaningful. I'll stick with the original logic in this patch, but if we find more problems in the same area we should consider that approach. Per bug #14641 from Denis Smirnov. Back-patch to 9.5 where this logic was introduced. Discussion: https://postgr.es/m/20170504072034.24366.57688@wrigleys.postgresql.org
Diffstat (limited to 'src/test/regress/sql/gist.sql')
-rw-r--r--src/test/regress/sql/gist.sql16
1 files changed, 16 insertions, 0 deletions
diff --git a/src/test/regress/sql/gist.sql b/src/test/regress/sql/gist.sql
index 9d4ff1e97e9..49126fd466d 100644
--- a/src/test/regress/sql/gist.sql
+++ b/src/test/regress/sql/gist.sql
@@ -69,6 +69,22 @@ order by point(0.101, 0.101) <-> p;
select p from gist_tbl where p <@ box(point(0,0), point(0.5, 0.5))
order by point(0.101, 0.101) <-> p;
+-- Check case with multiple rescans (bug #14641)
+explain (costs off)
+select p from
+ (values (box(point(0,0), point(0.5,0.5))),
+ (box(point(0.5,0.5), point(0.75,0.75))),
+ (box(point(0.8,0.8), point(1.0,1.0)))) as v(bb)
+cross join lateral
+ (select p from gist_tbl where p <@ bb order by p <-> bb[0] limit 2) ss;
+
+select p from
+ (values (box(point(0,0), point(0.5,0.5))),
+ (box(point(0.5,0.5), point(0.75,0.75))),
+ (box(point(0.8,0.8), point(1.0,1.0)))) as v(bb)
+cross join lateral
+ (select p from gist_tbl where p <@ bb order by p <-> bb[0] limit 2) ss;
+
drop index gist_tbl_point_index;
-- Test index-only scan with box opclass