database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-27 12:41:57 +03:00
Code Activity

Fix wrong order of operations in inheritance_planner.

Browse Source 
When considering a partitioning parent rel, we should stop processing that
subroot as soon as we've done adjust_appendrel_attrs and any securityQuals
updates.  The rest of this is unnecessary, and indeed adding duplicate
subquery RTEs to the subroot is *wrong*.  As the code stood, the children
of that partition ended up with two sets of copied subquery RTEs, confusing
matters greatly.  Even more hilarity ensued if all of the children got
excluded by constraint exclusion, so that the extra RTEs didn't make it
back into the parent rtable.

Per fuzz testing by Andreas Seltenreich.  Back-patch to v11 where this
got broken (by commit 0a480502b, it looks like).

Discussion: https://postgr.es/m/87va8g7vq0.fsf@ansel.ydns.eu
This commit is contained in:
Tom Lane
2018-08-11 15:53:20 -04:00
parent a2a8acd152
commit 4a2994f055
3 changed files with 111 additions and 50 deletions
Download Patch File Download Diff File Expand all files Collapse all files

43
src/test/regress/expected/partition_join.out
View File

@ -1722,6 +1722,49 @@ SELECT t1.a, t1.c, t2.b, t2.c FROM (SELECT * FROM prt1_l WHERE a = 1 AND a = 2)
One-Time Filter: false
(11 rows)
-- Test case to verify proper handling of subqueries in a partitioned delete.
-- The weird-looking lateral join is just there to force creation of a
-- nestloop parameter within the subquery, which exposes the problem if the
-- planner fails to make multiple copies of the subquery as appropriate.
EXPLAIN (COSTS OFF)
DELETE FROM prt1_l
WHERE EXISTS (
SELECT 1
FROM int4_tbl,
LATERAL (SELECT int4_tbl.f1 FROM int8_tbl LIMIT 2) ss
WHERE prt1_l.c IS NULL);
QUERY PLAN
---------------------------------------------------------------
Delete on prt1_l
Delete on prt1_l_p1
Delete on prt1_l_p3_p1
Delete on prt1_l_p3_p2
-> Nested Loop Semi Join
-> Seq Scan on prt1_l_p1
Filter: (c IS NULL)
-> Nested Loop
-> Seq Scan on int4_tbl
-> Subquery Scan on ss
-> Limit
-> Seq Scan on int8_tbl
-> Nested Loop Semi Join
-> Seq Scan on prt1_l_p3_p1
Filter: (c IS NULL)
-> Nested Loop
-> Seq Scan on int4_tbl
-> Subquery Scan on ss_1
-> Limit
-> Seq Scan on int8_tbl int8_tbl_1
-> Nested Loop Semi Join
-> Seq Scan on prt1_l_p3_p2
Filter: (c IS NULL)
-> Nested Loop
-> Seq Scan on int4_tbl
-> Subquery Scan on ss_2
-> Limit
-> Seq Scan on int8_tbl int8_tbl_2
(28 rows)
--
-- negative testcases
--

12
src/test/regress/sql/partition_join.sql
View File

@ -340,6 +340,18 @@ SELECT * FROM prt1_l t1 LEFT JOIN LATERAL
EXPLAIN (COSTS OFF)
SELECT t1.a, t1.c, t2.b, t2.c FROM (SELECT * FROM prt1_l WHERE a = 1 AND a = 2) t1 RIGHT JOIN prt2_l t2 ON t1.a = t2.b AND t1.b = t2.a AND t1.c = t2.c;
-- Test case to verify proper handling of subqueries in a partitioned delete.
-- The weird-looking lateral join is just there to force creation of a
-- nestloop parameter within the subquery, which exposes the problem if the
-- planner fails to make multiple copies of the subquery as appropriate.
EXPLAIN (COSTS OFF)
DELETE FROM prt1_l
WHERE EXISTS (
SELECT 1
FROM int4_tbl,
LATERAL (SELECT int4_tbl.f1 FROM int8_tbl LIMIT 2) ss
WHERE prt1_l.c IS NULL);
--
-- negative testcases
--