pg.ddx.io pgsql-committers@postgresql.org mailing list archive
help / color / mirror / Atom feedpgsql: Merge psql \df options into a single \? line, and update docs.
6+ messages / 2 participants
[nested] [flat]
* pgsql: Merge psql \df options into a single \? line, and update docs.
@ 2009-04-21 17:23 Bruce Momjian <momjian@postgresql.org>
0 siblings, 0 replies; 6+ messages in thread
From: momjian@postgresql.org @ 2009-04-21 17:23 UTC (permalink / raw)
To: pgsql-committers
Log Message:
-----------
Merge psql \df options into a single \? line, and update docs.
Modified Files:
--------------
pgsql/doc/src/sgml/ref:
psql-ref.sgml (r1.224 -> r1.225)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/ref/psql-ref.sgml?r1=1.224&r2=1.225)
pgsql/src/bin/psql:
help.c (r1.147 -> r1.148)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/bin/psql/help.c?r1=1.147&r2=1.148)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Apply band-aid fix for an oversight in reparameterize_path_by_ch
@ 2024-02-01 17:34 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 6+ messages in thread
From: Tom Lane @ 2024-02-01 17:34 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Apply band-aid fix for an oversight in reparameterize_path_by_child.
The path we wish to reparameterize is not a standalone object:
in particular, it implicitly references baserestrictinfo clauses
in the associated RelOptInfo, and if it's a SampleScan path then
there is also the TableSampleClause in the RTE to worry about.
Both of those could contain lateral references to the join partner
relation, which would need to be modified to refer to its child.
Since we aren't doing that, affected queries can give wrong answers,
or odd failures such as "variable not found in subplan target list",
or executor crashes. But we can't just summarily modify those
expressions, because they are shared with other paths for the rel.
We'd break things if we modify them and then end up using some
non-partitioned-join path.
In HEAD, we plan to fix this by postponing reparameterization
until create_plan(), when we know that those other paths are
no longer of interest, and then adjusting those expressions along
with the ones in the path itself. That seems like too big a change
for stable branches however. In the back branches, let's just detect
whether any troublesome lateral references actually exist in those
expressions, and fail reparameterization if so. This will result in
not performing a partitioned join in such cases. Given the lack of
field complaints, nobody's likely to miss the optimization.
Report and patch by Richard Guo. Apply to 12-16 only, since
the intended fix for HEAD looks quite different. We're not quite
ready to push the HEAD fix, but with back-branch releases coming
up soon, it seems wise to get this stopgap fix in place there.
Discussion: https://postgr.es/m/CAMbWs496+N=UAjOc=rcD3P7B6oJe4rZw08e_TZRUsWbPxZW3Tw@mail.gmail.com
Branch
------
REL_16_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/62f12020314792cafc7d5e631a3c98cfd33b5fb9
Modified Files
--------------
src/backend/optimizer/util/pathnode.c | 175 +++++++++++++++++++++++++++
src/test/regress/expected/partition_join.out | 167 +++++++++++++++++++++++++
src/test/regress/sql/partition_join.sql | 48 ++++++++
3 files changed, 390 insertions(+)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Apply band-aid fix for an oversight in reparameterize_path_by_ch
@ 2024-02-01 17:34 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 6+ messages in thread
From: Tom Lane @ 2024-02-01 17:34 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Apply band-aid fix for an oversight in reparameterize_path_by_child.
The path we wish to reparameterize is not a standalone object:
in particular, it implicitly references baserestrictinfo clauses
in the associated RelOptInfo, and if it's a SampleScan path then
there is also the TableSampleClause in the RTE to worry about.
Both of those could contain lateral references to the join partner
relation, which would need to be modified to refer to its child.
Since we aren't doing that, affected queries can give wrong answers,
or odd failures such as "variable not found in subplan target list",
or executor crashes. But we can't just summarily modify those
expressions, because they are shared with other paths for the rel.
We'd break things if we modify them and then end up using some
non-partitioned-join path.
In HEAD, we plan to fix this by postponing reparameterization
until create_plan(), when we know that those other paths are
no longer of interest, and then adjusting those expressions along
with the ones in the path itself. That seems like too big a change
for stable branches however. In the back branches, let's just detect
whether any troublesome lateral references actually exist in those
expressions, and fail reparameterization if so. This will result in
not performing a partitioned join in such cases. Given the lack of
field complaints, nobody's likely to miss the optimization.
Report and patch by Richard Guo. Apply to 12-16 only, since
the intended fix for HEAD looks quite different. We're not quite
ready to push the HEAD fix, but with back-branch releases coming
up soon, it seems wise to get this stopgap fix in place there.
Discussion: https://postgr.es/m/CAMbWs496+N=UAjOc=rcD3P7B6oJe4rZw08e_TZRUsWbPxZW3Tw@mail.gmail.com
Branch
------
REL_15_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/12ec16d11c8bd75624a77ae7a456ceec8332c9d9
Modified Files
--------------
src/backend/optimizer/util/pathnode.c | 175 +++++++++++++++++++++++++++
src/test/regress/expected/partition_join.out | 167 +++++++++++++++++++++++++
src/test/regress/sql/partition_join.sql | 48 ++++++++
3 files changed, 390 insertions(+)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Apply band-aid fix for an oversight in reparameterize_path_by_ch
@ 2024-02-01 17:34 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 6+ messages in thread
From: Tom Lane @ 2024-02-01 17:34 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Apply band-aid fix for an oversight in reparameterize_path_by_child.
The path we wish to reparameterize is not a standalone object:
in particular, it implicitly references baserestrictinfo clauses
in the associated RelOptInfo, and if it's a SampleScan path then
there is also the TableSampleClause in the RTE to worry about.
Both of those could contain lateral references to the join partner
relation, which would need to be modified to refer to its child.
Since we aren't doing that, affected queries can give wrong answers,
or odd failures such as "variable not found in subplan target list",
or executor crashes. But we can't just summarily modify those
expressions, because they are shared with other paths for the rel.
We'd break things if we modify them and then end up using some
non-partitioned-join path.
In HEAD, we plan to fix this by postponing reparameterization
until create_plan(), when we know that those other paths are
no longer of interest, and then adjusting those expressions along
with the ones in the path itself. That seems like too big a change
for stable branches however. In the back branches, let's just detect
whether any troublesome lateral references actually exist in those
expressions, and fail reparameterization if so. This will result in
not performing a partitioned join in such cases. Given the lack of
field complaints, nobody's likely to miss the optimization.
Report and patch by Richard Guo. Apply to 12-16 only, since
the intended fix for HEAD looks quite different. We're not quite
ready to push the HEAD fix, but with back-branch releases coming
up soon, it seems wise to get this stopgap fix in place there.
Discussion: https://postgr.es/m/CAMbWs496+N=UAjOc=rcD3P7B6oJe4rZw08e_TZRUsWbPxZW3Tw@mail.gmail.com
Branch
------
REL_14_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/e031995d5c26cf4567cda0ae47e44011409cb2df
Modified Files
--------------
src/backend/optimizer/util/pathnode.c | 175 +++++++++++++++++++++++++++
src/test/regress/expected/partition_join.out | 167 +++++++++++++++++++++++++
src/test/regress/sql/partition_join.sql | 48 ++++++++
3 files changed, 390 insertions(+)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Apply band-aid fix for an oversight in reparameterize_path_by_ch
@ 2024-02-01 17:34 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 6+ messages in thread
From: Tom Lane @ 2024-02-01 17:34 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Apply band-aid fix for an oversight in reparameterize_path_by_child.
The path we wish to reparameterize is not a standalone object:
in particular, it implicitly references baserestrictinfo clauses
in the associated RelOptInfo, and if it's a SampleScan path then
there is also the TableSampleClause in the RTE to worry about.
Both of those could contain lateral references to the join partner
relation, which would need to be modified to refer to its child.
Since we aren't doing that, affected queries can give wrong answers,
or odd failures such as "variable not found in subplan target list",
or executor crashes. But we can't just summarily modify those
expressions, because they are shared with other paths for the rel.
We'd break things if we modify them and then end up using some
non-partitioned-join path.
In HEAD, we plan to fix this by postponing reparameterization
until create_plan(), when we know that those other paths are
no longer of interest, and then adjusting those expressions along
with the ones in the path itself. That seems like too big a change
for stable branches however. In the back branches, let's just detect
whether any troublesome lateral references actually exist in those
expressions, and fail reparameterization if so. This will result in
not performing a partitioned join in such cases. Given the lack of
field complaints, nobody's likely to miss the optimization.
Report and patch by Richard Guo. Apply to 12-16 only, since
the intended fix for HEAD looks quite different. We're not quite
ready to push the HEAD fix, but with back-branch releases coming
up soon, it seems wise to get this stopgap fix in place there.
Discussion: https://postgr.es/m/CAMbWs496+N=UAjOc=rcD3P7B6oJe4rZw08e_TZRUsWbPxZW3Tw@mail.gmail.com
Branch
------
REL_13_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/7af96a66f43cdb0b07956a36412b3b0da260b56e
Modified Files
--------------
src/backend/optimizer/util/pathnode.c | 175 +++++++++++++++++++++++++++
src/test/regress/expected/partition_join.out | 167 +++++++++++++++++++++++++
src/test/regress/sql/partition_join.sql | 48 ++++++++
3 files changed, 390 insertions(+)
^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Apply band-aid fix for an oversight in reparameterize_path_by_ch
@ 2024-02-01 17:34 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 6+ messages in thread
From: Tom Lane @ 2024-02-01 17:34 UTC (permalink / raw)
To: pgsql-committers@lists.postgresql.org
Apply band-aid fix for an oversight in reparameterize_path_by_child.
The path we wish to reparameterize is not a standalone object:
in particular, it implicitly references baserestrictinfo clauses
in the associated RelOptInfo, and if it's a SampleScan path then
there is also the TableSampleClause in the RTE to worry about.
Both of those could contain lateral references to the join partner
relation, which would need to be modified to refer to its child.
Since we aren't doing that, affected queries can give wrong answers,
or odd failures such as "variable not found in subplan target list",
or executor crashes. But we can't just summarily modify those
expressions, because they are shared with other paths for the rel.
We'd break things if we modify them and then end up using some
non-partitioned-join path.
In HEAD, we plan to fix this by postponing reparameterization
until create_plan(), when we know that those other paths are
no longer of interest, and then adjusting those expressions along
with the ones in the path itself. That seems like too big a change
for stable branches however. In the back branches, let's just detect
whether any troublesome lateral references actually exist in those
expressions, and fail reparameterization if so. This will result in
not performing a partitioned join in such cases. Given the lack of
field complaints, nobody's likely to miss the optimization.
Report and patch by Richard Guo. Apply to 12-16 only, since
the intended fix for HEAD looks quite different. We're not quite
ready to push the HEAD fix, but with back-branch releases coming
up soon, it seems wise to get this stopgap fix in place there.
Discussion: https://postgr.es/m/CAMbWs496+N=UAjOc=rcD3P7B6oJe4rZw08e_TZRUsWbPxZW3Tw@mail.gmail.com
Branch
------
REL_12_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/2e822a1d62d0f78b7d471076ea982cd0734cc875
Modified Files
--------------
src/backend/optimizer/util/pathnode.c | 175 +++++++++++++++++++++++++++
src/test/regress/expected/partition_join.out | 167 +++++++++++++++++++++++++
src/test/regress/sql/partition_join.sql | 48 ++++++++
3 files changed, 390 insertions(+)
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2024-02-01 17:34 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2009-04-21 17:23 pgsql: Merge psql \df options into a single \? line, and update docs. Bruce Momjian <momjian@postgresql.org>
2024-02-01 17:34 pgsql: Apply band-aid fix for an oversight in reparameterize_path_by_ch Tom Lane <tgl@sss.pgh.pa.us>
2024-02-01 17:34 pgsql: Apply band-aid fix for an oversight in reparameterize_path_by_ch Tom Lane <tgl@sss.pgh.pa.us>
2024-02-01 17:34 pgsql: Apply band-aid fix for an oversight in reparameterize_path_by_ch Tom Lane <tgl@sss.pgh.pa.us>
2024-02-01 17:34 pgsql: Apply band-aid fix for an oversight in reparameterize_path_by_ch Tom Lane <tgl@sss.pgh.pa.us>
2024-02-01 17:34 pgsql: Apply band-aid fix for an oversight in reparameterize_path_by_ch Tom Lane <tgl@sss.pgh.pa.us>
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