pg.ddx.io  pgsql-committers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
pgsql: Fix planner error when estimating SubPlan cost
7+ messages / 1 participants
[nested] [flat]

* pgsql: Fix planner error when estimating SubPlan cost
@ 2025-09-03 07:02  Richard Guo <rguo@postgresql.org>
  0 siblings, 0 replies; 7+ messages in thread

From: Richard Guo @ 2025-09-03 07:02 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Fix planner error when estimating SubPlan cost

SubPlan nodes are typically built very early, before any RelOptInfos
have been constructed for the parent query level.  As a result, the
simple_rel_array in the parent root has not yet been initialized.
Currently, during cost estimation of a SubPlan's testexpr, we may call
examine_variable() to look up statistical data about the expressions.
This can lead to "no relation entry for relid" errors.

To fix, pass root as NULL to cost_qual_eval() in cost_subplan(), since
the root does not yet contain enough information to safely consult
statistics.

One exception is SubPlan nodes built for the initplans of MIN/MAX
aggregates from indexes.  In this case, having a NULL root is safe
because testexpr will be NULL.  Additionally, an initplan will by
definition not consult anything from the parent plan.

Backpatch to all supported branches.  Although the reported call path
that triggers this error is not reachable prior to v17, there's no
guarantee that other code paths -- especially in extensions -- could
not encounter the same issue when cost_qual_eval() is called with a
root that lacks a valid simple_rel_array.  The test case is not
included in pre-v17 branches though.

Bug: #19037
Reported-by: Alexander Lakhin <exclusion@gmail.com>
Diagnosed-by: Tom Lane <tgl@sss.pgh.pa.us>
Author: Richard Guo <guofenglinux@gmail.com>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/19037-3d1c7bb553c7ce84@postgresql.org
Backpatch-through: 13

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/aba8f61c30911cbac1a310b7d21777e04711c66e

Modified Files
--------------
src/backend/optimizer/path/costsize.c   | 18 ++++++++++++++++--
src/test/regress/expected/subselect.out | 19 +++++++++++++++++++
src/test/regress/sql/subselect.sql      |  9 +++++++++
3 files changed, 44 insertions(+), 2 deletions(-)



^ permalink  raw  reply  [nested|flat] 7+ messages in thread

* pgsql: Fix planner error when estimating SubPlan cost
@ 2025-09-03 07:04  Richard Guo <rguo@postgresql.org>
  0 siblings, 0 replies; 7+ messages in thread

From: Richard Guo @ 2025-09-03 07:04 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Fix planner error when estimating SubPlan cost

SubPlan nodes are typically built very early, before any RelOptInfos
have been constructed for the parent query level.  As a result, the
simple_rel_array in the parent root has not yet been initialized.
Currently, during cost estimation of a SubPlan's testexpr, we may call
examine_variable() to look up statistical data about the expressions.
This can lead to "no relation entry for relid" errors.

To fix, pass root as NULL to cost_qual_eval() in cost_subplan(), since
the root does not yet contain enough information to safely consult
statistics.

One exception is SubPlan nodes built for the initplans of MIN/MAX
aggregates from indexes.  In this case, having a NULL root is safe
because testexpr will be NULL.  Additionally, an initplan will by
definition not consult anything from the parent plan.

Backpatch to all supported branches.  Although the reported call path
that triggers this error is not reachable prior to v17, there's no
guarantee that other code paths -- especially in extensions -- could
not encounter the same issue when cost_qual_eval() is called with a
root that lacks a valid simple_rel_array.  The test case is not
included in pre-v17 branches though.

Bug: #19037
Reported-by: Alexander Lakhin <exclusion@gmail.com>
Diagnosed-by: Tom Lane <tgl@sss.pgh.pa.us>
Author: Richard Guo <guofenglinux@gmail.com>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/19037-3d1c7bb553c7ce84@postgresql.org
Backpatch-through: 13

Branch
------
REL_18_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/ab4a35b4ea9d2290b1ee5ec25f65df4c739077cb

Modified Files
--------------
src/backend/optimizer/path/costsize.c   | 18 ++++++++++++++++--
src/test/regress/expected/subselect.out | 19 +++++++++++++++++++
src/test/regress/sql/subselect.sql      |  9 +++++++++
3 files changed, 44 insertions(+), 2 deletions(-)



^ permalink  raw  reply  [nested|flat] 7+ messages in thread

* pgsql: Fix planner error when estimating SubPlan cost
@ 2025-09-03 07:06  Richard Guo <rguo@postgresql.org>
  0 siblings, 0 replies; 7+ messages in thread

From: Richard Guo @ 2025-09-03 07:06 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Fix planner error when estimating SubPlan cost

SubPlan nodes are typically built very early, before any RelOptInfos
have been constructed for the parent query level.  As a result, the
simple_rel_array in the parent root has not yet been initialized.
Currently, during cost estimation of a SubPlan's testexpr, we may call
examine_variable() to look up statistical data about the expressions.
This can lead to "no relation entry for relid" errors.

To fix, pass root as NULL to cost_qual_eval() in cost_subplan(), since
the root does not yet contain enough information to safely consult
statistics.

One exception is SubPlan nodes built for the initplans of MIN/MAX
aggregates from indexes.  In this case, having a NULL root is safe
because testexpr will be NULL.  Additionally, an initplan will by
definition not consult anything from the parent plan.

Backpatch to all supported branches.  Although the reported call path
that triggers this error is not reachable prior to v17, there's no
guarantee that other code paths -- especially in extensions -- could
not encounter the same issue when cost_qual_eval() is called with a
root that lacks a valid simple_rel_array.  The test case is not
included in pre-v17 branches though.

Bug: #19037
Reported-by: Alexander Lakhin <exclusion@gmail.com>
Diagnosed-by: Tom Lane <tgl@sss.pgh.pa.us>
Author: Richard Guo <guofenglinux@gmail.com>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/19037-3d1c7bb553c7ce84@postgresql.org
Backpatch-through: 13

Branch
------
REL_17_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/f34202f51867534fbbb6196fc9e77be25e5e5b23

Modified Files
--------------
src/backend/optimizer/path/costsize.c   | 18 ++++++++++++++++--
src/test/regress/expected/subselect.out | 19 +++++++++++++++++++
src/test/regress/sql/subselect.sql      |  9 +++++++++
3 files changed, 44 insertions(+), 2 deletions(-)



^ permalink  raw  reply  [nested|flat] 7+ messages in thread

* pgsql: Fix planner error when estimating SubPlan cost
@ 2025-09-03 07:10  Richard Guo <rguo@postgresql.org>
  0 siblings, 0 replies; 7+ messages in thread

From: Richard Guo @ 2025-09-03 07:10 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Fix planner error when estimating SubPlan cost

SubPlan nodes are typically built very early, before any RelOptInfos
have been constructed for the parent query level.  As a result, the
simple_rel_array in the parent root has not yet been initialized.
Currently, during cost estimation of a SubPlan's testexpr, we may call
examine_variable() to look up statistical data about the expressions.
This can lead to "no relation entry for relid" errors.

To fix, pass root as NULL to cost_qual_eval() in cost_subplan(), since
the root does not yet contain enough information to safely consult
statistics.

One exception is SubPlan nodes built for the initplans of MIN/MAX
aggregates from indexes.  In this case, having a NULL root is safe
because testexpr will be NULL.  Additionally, an initplan will by
definition not consult anything from the parent plan.

Backpatch to all supported branches.  Although the reported call path
that triggers this error is not reachable prior to v17, there's no
guarantee that other code paths -- especially in extensions -- could
not encounter the same issue when cost_qual_eval() is called with a
root that lacks a valid simple_rel_array.  The test case is not
included in pre-v17 branches though.

Bug: #19037
Reported-by: Alexander Lakhin <exclusion@gmail.com>
Diagnosed-by: Tom Lane <tgl@sss.pgh.pa.us>
Author: Richard Guo <guofenglinux@gmail.com>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/19037-3d1c7bb553c7ce84@postgresql.org
Backpatch-through: 13

Branch
------
REL_16_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/79ade5873232c5dea225345c78f1632c22cbb05a

Modified Files
--------------
src/backend/optimizer/path/costsize.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)



^ permalink  raw  reply  [nested|flat] 7+ messages in thread

* pgsql: Fix planner error when estimating SubPlan cost
@ 2025-09-03 07:14  Richard Guo <rguo@postgresql.org>
  0 siblings, 0 replies; 7+ messages in thread

From: Richard Guo @ 2025-09-03 07:14 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Fix planner error when estimating SubPlan cost

SubPlan nodes are typically built very early, before any RelOptInfos
have been constructed for the parent query level.  As a result, the
simple_rel_array in the parent root has not yet been initialized.
Currently, during cost estimation of a SubPlan's testexpr, we may call
examine_variable() to look up statistical data about the expressions.
This can lead to "no relation entry for relid" errors.

To fix, pass root as NULL to cost_qual_eval() in cost_subplan(), since
the root does not yet contain enough information to safely consult
statistics.

One exception is SubPlan nodes built for the initplans of MIN/MAX
aggregates from indexes.  In this case, having a NULL root is safe
because testexpr will be NULL.  Additionally, an initplan will by
definition not consult anything from the parent plan.

Backpatch to all supported branches.  Although the reported call path
that triggers this error is not reachable prior to v17, there's no
guarantee that other code paths -- especially in extensions -- could
not encounter the same issue when cost_qual_eval() is called with a
root that lacks a valid simple_rel_array.  The test case is not
included in pre-v17 branches though.

Bug: #19037
Reported-by: Alexander Lakhin <exclusion@gmail.com>
Diagnosed-by: Tom Lane <tgl@sss.pgh.pa.us>
Author: Richard Guo <guofenglinux@gmail.com>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/19037-3d1c7bb553c7ce84@postgresql.org
Backpatch-through: 13

Branch
------
REL_15_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/53e35fb560abe1e32dd3a831acde8bfdb34a6a70

Modified Files
--------------
src/backend/optimizer/path/costsize.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)



^ permalink  raw  reply  [nested|flat] 7+ messages in thread

* pgsql: Fix planner error when estimating SubPlan cost
@ 2025-09-03 07:17  Richard Guo <rguo@postgresql.org>
  0 siblings, 0 replies; 7+ messages in thread

From: Richard Guo @ 2025-09-03 07:17 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Fix planner error when estimating SubPlan cost

SubPlan nodes are typically built very early, before any RelOptInfos
have been constructed for the parent query level.  As a result, the
simple_rel_array in the parent root has not yet been initialized.
Currently, during cost estimation of a SubPlan's testexpr, we may call
examine_variable() to look up statistical data about the expressions.
This can lead to "no relation entry for relid" errors.

To fix, pass root as NULL to cost_qual_eval() in cost_subplan(), since
the root does not yet contain enough information to safely consult
statistics.

One exception is SubPlan nodes built for the initplans of MIN/MAX
aggregates from indexes.  In this case, having a NULL root is safe
because testexpr will be NULL.  Additionally, an initplan will by
definition not consult anything from the parent plan.

Backpatch to all supported branches.  Although the reported call path
that triggers this error is not reachable prior to v17, there's no
guarantee that other code paths -- especially in extensions -- could
not encounter the same issue when cost_qual_eval() is called with a
root that lacks a valid simple_rel_array.  The test case is not
included in pre-v17 branches though.

Bug: #19037
Reported-by: Alexander Lakhin <exclusion@gmail.com>
Diagnosed-by: Tom Lane <tgl@sss.pgh.pa.us>
Author: Richard Guo <guofenglinux@gmail.com>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/19037-3d1c7bb553c7ce84@postgresql.org
Backpatch-through: 13

Branch
------
REL_14_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/160ef51c8dbab47b04c5aa65b6909e7be5ec5af6

Modified Files
--------------
src/backend/optimizer/path/costsize.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)



^ permalink  raw  reply  [nested|flat] 7+ messages in thread

* pgsql: Fix planner error when estimating SubPlan cost
@ 2025-09-03 07:20  Richard Guo <rguo@postgresql.org>
  0 siblings, 0 replies; 7+ messages in thread

From: Richard Guo @ 2025-09-03 07:20 UTC (permalink / raw)
  To: pgsql-committers@lists.postgresql.org

Fix planner error when estimating SubPlan cost

SubPlan nodes are typically built very early, before any RelOptInfos
have been constructed for the parent query level.  As a result, the
simple_rel_array in the parent root has not yet been initialized.
Currently, during cost estimation of a SubPlan's testexpr, we may call
examine_variable() to look up statistical data about the expressions.
This can lead to "no relation entry for relid" errors.

To fix, pass root as NULL to cost_qual_eval() in cost_subplan(), since
the root does not yet contain enough information to safely consult
statistics.

One exception is SubPlan nodes built for the initplans of MIN/MAX
aggregates from indexes.  In this case, having a NULL root is safe
because testexpr will be NULL.  Additionally, an initplan will by
definition not consult anything from the parent plan.

Backpatch to all supported branches.  Although the reported call path
that triggers this error is not reachable prior to v17, there's no
guarantee that other code paths -- especially in extensions -- could
not encounter the same issue when cost_qual_eval() is called with a
root that lacks a valid simple_rel_array.  The test case is not
included in pre-v17 branches though.

Bug: #19037
Reported-by: Alexander Lakhin <exclusion@gmail.com>
Diagnosed-by: Tom Lane <tgl@sss.pgh.pa.us>
Author: Richard Guo <guofenglinux@gmail.com>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/19037-3d1c7bb553c7ce84@postgresql.org
Backpatch-through: 13

Branch
------
REL_13_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/8c02d92c6475c2488f6e64b9096d812713692f82

Modified Files
--------------
src/backend/optimizer/path/costsize.c | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)



^ permalink  raw  reply  [nested|flat] 7+ messages in thread


end of thread, other threads:[~2025-09-03 07:20 UTC | newest]

Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-09-03 07:02 pgsql: Fix planner error when estimating SubPlan cost Richard Guo <rguo@postgresql.org>
2025-09-03 07:04 pgsql: Fix planner error when estimating SubPlan cost Richard Guo <rguo@postgresql.org>
2025-09-03 07:06 pgsql: Fix planner error when estimating SubPlan cost Richard Guo <rguo@postgresql.org>
2025-09-03 07:10 pgsql: Fix planner error when estimating SubPlan cost Richard Guo <rguo@postgresql.org>
2025-09-03 07:14 pgsql: Fix planner error when estimating SubPlan cost Richard Guo <rguo@postgresql.org>
2025-09-03 07:17 pgsql: Fix planner error when estimating SubPlan cost Richard Guo <rguo@postgresql.org>
2025-09-03 07:20 pgsql: Fix planner error when estimating SubPlan cost 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