summaryrefslogtreecommitdiff
path: root/contrib/btree_gist
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2016-06-05 11:53:06 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2016-06-05 11:53:06 -0400
commita7aa61ffe7ed12cf8d5cbdfc887900549f9ed354 (patch)
treec889756c49dbbb62c50727f5257049b3591530fb /contrib/btree_gist
parentc82037e372394ee046e278887c8f938591ca7406 (diff)
downloadpostgresql-a7aa61ffe7ed12cf8d5cbdfc887900549f9ed354.tar.gz
Properly initialize SortSupport for ORDER BY rechecks in nodeIndexscan.c.
Fix still another bug in commit 35fcb1b3d: it failed to fully initialize the SortSupport states it introduced to allow the executor to re-check ORDER BY expressions containing distance operators. That led to a null pointer dereference if the sortsupport code tried to use ssup_cxt. The problem only manifests in narrow cases, explaining the lack of previous field reports. It requires a GiST-indexable distance operator that lacks SortSupport and is on a pass-by-ref data type, which among core+contrib seems to be only btree_gist's interval opclass; and it requires the scan to be done as an IndexScan not an IndexOnlyScan, which explains how btree_gist's regression test didn't catch it. Per bug #14134 from Jihyun Yu. Peter Geoghegan Report: <20160511154904.2603.43889@wrigleys.postgresql.org>
Diffstat (limited to 'contrib/btree_gist')
-rw-r--r--contrib/btree_gist/expected/interval.out18
-rw-r--r--contrib/btree_gist/sql/interval.sql6
2 files changed, 24 insertions, 0 deletions
diff --git a/contrib/btree_gist/expected/interval.out b/contrib/btree_gist/expected/interval.out
index 875380978e..4c3d494e4a 100644
--- a/contrib/btree_gist/expected/interval.out
+++ b/contrib/btree_gist/expected/interval.out
@@ -89,3 +89,21 @@ SELECT a, a <-> '199 days 21:21:23' FROM intervaltmp ORDER BY a <-> '199 days 21
@ 220 days 19 hours 5 mins 42 secs | @ 21 days -2 hours -15 mins -41 secs
(3 rows)
+SET enable_indexonlyscan=off;
+EXPLAIN (COSTS OFF)
+SELECT a, a <-> '199 days 21:21:23' FROM intervaltmp ORDER BY a <-> '199 days 21:21:23' LIMIT 3;
+ QUERY PLAN
+---------------------------------------------------------------------------
+ Limit
+ -> Index Scan using intervalidx on intervaltmp
+ Order By: (a <-> '@ 199 days 21 hours 21 mins 23 secs'::interval)
+(3 rows)
+
+SELECT a, a <-> '199 days 21:21:23' FROM intervaltmp ORDER BY a <-> '199 days 21:21:23' LIMIT 3;
+ a | ?column?
+-------------------------------------+--------------------------------------
+ @ 199 days 21 hours 21 mins 23 secs | @ 0
+ @ 183 days 6 hours 52 mins 48 secs | @ 16 days 14 hours 28 mins 35 secs
+ @ 220 days 19 hours 5 mins 42 secs | @ 21 days -2 hours -15 mins -41 secs
+(3 rows)
+
diff --git a/contrib/btree_gist/sql/interval.sql b/contrib/btree_gist/sql/interval.sql
index 0f8b031520..346d6adcb5 100644
--- a/contrib/btree_gist/sql/interval.sql
+++ b/contrib/btree_gist/sql/interval.sql
@@ -35,3 +35,9 @@ SELECT count(*) FROM intervaltmp WHERE a > '199 days 21:21:23'::interval;
EXPLAIN (COSTS OFF)
SELECT a, a <-> '199 days 21:21:23' FROM intervaltmp ORDER BY a <-> '199 days 21:21:23' LIMIT 3;
SELECT a, a <-> '199 days 21:21:23' FROM intervaltmp ORDER BY a <-> '199 days 21:21:23' LIMIT 3;
+
+SET enable_indexonlyscan=off;
+
+EXPLAIN (COSTS OFF)
+SELECT a, a <-> '199 days 21:21:23' FROM intervaltmp ORDER BY a <-> '199 days 21:21:23' LIMIT 3;
+SELECT a, a <-> '199 days 21:21:23' FROM intervaltmp ORDER BY a <-> '199 days 21:21:23' LIMIT 3;