pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix computation of varnullingrels when const-folding field selec 6+ messages / 2 participants [nested] [flat]
* pgsql: Fix computation of varnullingrels when const-folding field selec @ 2023-11-09 20:46 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-11-09 20:46 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix computation of varnullingrels when const-folding field selection. We can simplify FieldSelect on a whole-row Var into a plain Var for the selected field. However, we should copy the whole-row Var's varnullingrels when we do so, because the new Var is clearly nullable by exactly the same rels as the original. Failure to do this led to errors like "wrong varnullingrels (b) (expected (b 3)) for Var 2/2". Richard Guo, per bug #18184 from Marian Krucina. Back-patch to v16 where varnullingrels was introduced. Discussion: https://postgr.es/m/18184-5868dd258782058e@postgresql.org Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/36f5594c0fe694600c07c803324b51fcfbea4079 Modified Files -------------- src/backend/optimizer/util/clauses.c | 19 +++++++++++++------ src/test/regress/expected/join.out | 26 ++++++++++++++++++++++++++ src/test/regress/sql/join.sql | 12 ++++++++++++ 3 files changed, 51 insertions(+), 6 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix computation of varnullingrels when const-folding field selec @ 2023-11-09 20:46 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 6+ messages in thread From: Tom Lane @ 2023-11-09 20:46 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix computation of varnullingrels when const-folding field selection. We can simplify FieldSelect on a whole-row Var into a plain Var for the selected field. However, we should copy the whole-row Var's varnullingrels when we do so, because the new Var is clearly nullable by exactly the same rels as the original. Failure to do this led to errors like "wrong varnullingrels (b) (expected (b 3)) for Var 2/2". Richard Guo, per bug #18184 from Marian Krucina. Back-patch to v16 where varnullingrels was introduced. Discussion: https://postgr.es/m/18184-5868dd258782058e@postgresql.org Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/6bf2efb38285626a9de3004dd1c23d9a85453372 Modified Files -------------- src/backend/optimizer/util/clauses.c | 19 +++++++++++++------ src/test/regress/expected/join.out | 26 ++++++++++++++++++++++++++ src/test/regress/sql/join.sql | 12 ++++++++++++ 3 files changed, 51 insertions(+), 6 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix computation of varnullingrels when translating appendrel Var @ 2026-02-20 09:08 Richard Guo <rguo@postgresql.org> 0 siblings, 0 replies; 6+ messages in thread From: Richard Guo @ 2026-02-20 09:08 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix computation of varnullingrels when translating appendrel Var When adjust_appendrel_attrs translates a Var referencing a parent relation into a Var referencing a child relation, it propagates varnullingrels from the parent Var to the translated Var. Previously, the code simply overwrote the translated Var's varnullingrels with those of the parent. This was incorrect because the translated Var might already possess nonempty varnullingrels. This happens, for example, when a LATERAL subquery within a UNION ALL references a Var from the nullable side of an outer join. In such cases, the translated Var correctly carries the outer join's relid in its varnullingrels. Overwriting these bits with the parent Var's set caused the planner to lose track of the fact that the Var could be nulled by that outer join. In the reported case, because the underlying column had a NOT NULL constraint, the planner incorrectly deduced that the Var could never be NULL and discarded essential IS NOT NULL filters. This led to incorrect query results where NULL rows were returned instead of being filtered out. To fix, use bms_add_members to merge the parent Var's varnullingrels into the translated Var's existing set, preserving both sources of nullability. Back-patch to v16. Although the reported case does not seem to cause problems in v16, leaving incorrect varnullingrels in the tree seems like a trap for the unwary. Bug: #19412 Reported-by: Sergey Shinderuk <s.shinderuk@postgrespro.ru> Author: Richard Guo <guofenglinux@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/19412-1d0318089b86859e@postgresql.org Backpatch-through: 16 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/691977d37037f30e39cc65f60e327f678f2cebe9 Modified Files -------------- src/backend/optimizer/util/appendinfo.c | 12 +++++--- src/test/regress/expected/join.out | 51 +++++++++++++++++++++++++++++++++ src/test/regress/sql/join.sql | 24 ++++++++++++++++ 3 files changed, 83 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix computation of varnullingrels when translating appendrel Var @ 2026-02-20 09:08 Richard Guo <rguo@postgresql.org> 0 siblings, 0 replies; 6+ messages in thread From: Richard Guo @ 2026-02-20 09:08 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix computation of varnullingrels when translating appendrel Var When adjust_appendrel_attrs translates a Var referencing a parent relation into a Var referencing a child relation, it propagates varnullingrels from the parent Var to the translated Var. Previously, the code simply overwrote the translated Var's varnullingrels with those of the parent. This was incorrect because the translated Var might already possess nonempty varnullingrels. This happens, for example, when a LATERAL subquery within a UNION ALL references a Var from the nullable side of an outer join. In such cases, the translated Var correctly carries the outer join's relid in its varnullingrels. Overwriting these bits with the parent Var's set caused the planner to lose track of the fact that the Var could be nulled by that outer join. In the reported case, because the underlying column had a NOT NULL constraint, the planner incorrectly deduced that the Var could never be NULL and discarded essential IS NOT NULL filters. This led to incorrect query results where NULL rows were returned instead of being filtered out. To fix, use bms_add_members to merge the parent Var's varnullingrels into the translated Var's existing set, preserving both sources of nullability. Back-patch to v16. Although the reported case does not seem to cause problems in v16, leaving incorrect varnullingrels in the tree seems like a trap for the unwary. Bug: #19412 Reported-by: Sergey Shinderuk <s.shinderuk@postgrespro.ru> Author: Richard Guo <guofenglinux@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/19412-1d0318089b86859e@postgresql.org Backpatch-through: 16 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/ed57c207c397a6e6a91e0394cacdc63e0f029173 Modified Files -------------- src/backend/optimizer/util/appendinfo.c | 12 +++++--- src/test/regress/expected/join.out | 51 +++++++++++++++++++++++++++++++++ src/test/regress/sql/join.sql | 24 ++++++++++++++++ 3 files changed, 83 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix computation of varnullingrels when translating appendrel Var @ 2026-02-20 09:08 Richard Guo <rguo@postgresql.org> 0 siblings, 0 replies; 6+ messages in thread From: Richard Guo @ 2026-02-20 09:08 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix computation of varnullingrels when translating appendrel Var When adjust_appendrel_attrs translates a Var referencing a parent relation into a Var referencing a child relation, it propagates varnullingrels from the parent Var to the translated Var. Previously, the code simply overwrote the translated Var's varnullingrels with those of the parent. This was incorrect because the translated Var might already possess nonempty varnullingrels. This happens, for example, when a LATERAL subquery within a UNION ALL references a Var from the nullable side of an outer join. In such cases, the translated Var correctly carries the outer join's relid in its varnullingrels. Overwriting these bits with the parent Var's set caused the planner to lose track of the fact that the Var could be nulled by that outer join. In the reported case, because the underlying column had a NOT NULL constraint, the planner incorrectly deduced that the Var could never be NULL and discarded essential IS NOT NULL filters. This led to incorrect query results where NULL rows were returned instead of being filtered out. To fix, use bms_add_members to merge the parent Var's varnullingrels into the translated Var's existing set, preserving both sources of nullability. Back-patch to v16. Although the reported case does not seem to cause problems in v16, leaving incorrect varnullingrels in the tree seems like a trap for the unwary. Bug: #19412 Reported-by: Sergey Shinderuk <s.shinderuk@postgrespro.ru> Author: Richard Guo <guofenglinux@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/19412-1d0318089b86859e@postgresql.org Backpatch-through: 16 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/bcaf1b5101c44a4549774ef047dafcbf46cfd904 Modified Files -------------- src/backend/optimizer/util/appendinfo.c | 12 ++++++-- src/test/regress/expected/join.out | 51 +++++++++++++++++++++++++++++++++ src/test/regress/sql/join.sql | 24 ++++++++++++++++ 3 files changed, 84 insertions(+), 3 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix computation of varnullingrels when translating appendrel Var @ 2026-02-20 09:08 Richard Guo <rguo@postgresql.org> 0 siblings, 0 replies; 6+ messages in thread From: Richard Guo @ 2026-02-20 09:08 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix computation of varnullingrels when translating appendrel Var When adjust_appendrel_attrs translates a Var referencing a parent relation into a Var referencing a child relation, it propagates varnullingrels from the parent Var to the translated Var. Previously, the code simply overwrote the translated Var's varnullingrels with those of the parent. This was incorrect because the translated Var might already possess nonempty varnullingrels. This happens, for example, when a LATERAL subquery within a UNION ALL references a Var from the nullable side of an outer join. In such cases, the translated Var correctly carries the outer join's relid in its varnullingrels. Overwriting these bits with the parent Var's set caused the planner to lose track of the fact that the Var could be nulled by that outer join. In the reported case, because the underlying column had a NOT NULL constraint, the planner incorrectly deduced that the Var could never be NULL and discarded essential IS NOT NULL filters. This led to incorrect query results where NULL rows were returned instead of being filtered out. To fix, use bms_add_members to merge the parent Var's varnullingrels into the translated Var's existing set, preserving both sources of nullability. Back-patch to v16. Although the reported case does not seem to cause problems in v16, leaving incorrect varnullingrels in the tree seems like a trap for the unwary. Bug: #19412 Reported-by: Sergey Shinderuk <s.shinderuk@postgrespro.ru> Author: Richard Guo <guofenglinux@gmail.com> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/19412-1d0318089b86859e@postgresql.org Backpatch-through: 16 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/ec20a45528bf1731bd532edd51cb68e5f341ac8f Modified Files -------------- src/backend/optimizer/util/appendinfo.c | 12 ++++++-- src/test/regress/expected/join.out | 52 +++++++++++++++++++++++++++++++++ src/test/regress/sql/join.sql | 24 +++++++++++++++ 3 files changed, 85 insertions(+), 3 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2026-02-20 09:08 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2023-11-09 20:46 pgsql: Fix computation of varnullingrels when const-folding field selec Tom Lane <tgl@sss.pgh.pa.us> 2023-11-09 20:46 pgsql: Fix computation of varnullingrels when const-folding field selec Tom Lane <tgl@sss.pgh.pa.us> 2026-02-20 09:08 pgsql: Fix computation of varnullingrels when translating appendrel Var Richard Guo <rguo@postgresql.org> 2026-02-20 09:08 pgsql: Fix computation of varnullingrels when translating appendrel Var Richard Guo <rguo@postgresql.org> 2026-02-20 09:08 pgsql: Fix computation of varnullingrels when translating appendrel Var Richard Guo <rguo@postgresql.org> 2026-02-20 09:08 pgsql: Fix computation of varnullingrels when translating appendrel Var Richard Guo <rguo@postgresql.org>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox