Re: pgsql: Fix potential NULL pointer dereference in getIdentitySequence()
Andrew Dunstan writes:
> On 2024-05-26 Su 07:58, Michael Paquier wrote:
>> Fix potential NULL pointer dereference in getIdentitySequence()
> This appears to have upset a number of buildfarm members
It's hard to see how that patch would have broken "configure",
and besides that the failures started earlier.
What it looks like from here is that Andres messed up the
installed-packages set on a lot of his animals.
regards, tom lane
pgsql: Remove race conditions between ECPGdebug() and ecpg_log().
Remove race conditions between ECPGdebug() and ecpg_log(). Coverity complains that ECPGdebug is accessing debugstream without holding debug_mutex, which is a fair complaint: we should take debug_mutex while changing the settings ecpg_log looks at. In some branches it also complains about unlocked use of simple_debug. I think it's intentional and safe to have a quick unlocked check of simple_debug at the start of ecpg_log, since that early exit will always be taken in non-debug cases. But we should recheck simple_debug after acquiring the mutex. In the worst case, calling ECPGdebug concurrently with ecpg_log in another thread could result in a null-pointer dereference due to debugstream transiently being NULL while simple_debug isn't 0. This is largely hypothetical, since it's unlikely anybody uses ECPGdebug() at all in the field, and our own regression tests don't seem to be hitting the theoretical race conditions either. Still, if we're going to the trouble of having mutexes here, we ought to be using them in a way that's actually safe not just almost safe. Hence, back-patch to all supported branches. Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2e062b65539ea9f85cf591ffbc4cd2db30bf5f51 Modified Files -- src/interfaces/ecpg/ecpglib/misc.c | 41 -- 1 file changed, 30 insertions(+), 11 deletions(-)
pgsql: Remove race conditions between ECPGdebug() and ecpg_log().
Remove race conditions between ECPGdebug() and ecpg_log(). Coverity complains that ECPGdebug is accessing debugstream without holding debug_mutex, which is a fair complaint: we should take debug_mutex while changing the settings ecpg_log looks at. In some branches it also complains about unlocked use of simple_debug. I think it's intentional and safe to have a quick unlocked check of simple_debug at the start of ecpg_log, since that early exit will always be taken in non-debug cases. But we should recheck simple_debug after acquiring the mutex. In the worst case, calling ECPGdebug concurrently with ecpg_log in another thread could result in a null-pointer dereference due to debugstream transiently being NULL while simple_debug isn't 0. This is largely hypothetical, since it's unlikely anybody uses ECPGdebug() at all in the field, and our own regression tests don't seem to be hitting the theoretical race conditions either. Still, if we're going to the trouble of having mutexes here, we ought to be using them in a way that's actually safe not just almost safe. Hence, back-patch to all supported branches. Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0795a35d13089c203f1b1ef523824c2fc22a6af9 Modified Files -- src/interfaces/ecpg/ecpglib/misc.c | 41 -- 1 file changed, 30 insertions(+), 11 deletions(-)
pgsql: Remove race conditions between ECPGdebug() and ecpg_log().
Remove race conditions between ECPGdebug() and ecpg_log(). Coverity complains that ECPGdebug is accessing debugstream without holding debug_mutex, which is a fair complaint: we should take debug_mutex while changing the settings ecpg_log looks at. In some branches it also complains about unlocked use of simple_debug. I think it's intentional and safe to have a quick unlocked check of simple_debug at the start of ecpg_log, since that early exit will always be taken in non-debug cases. But we should recheck simple_debug after acquiring the mutex. In the worst case, calling ECPGdebug concurrently with ecpg_log in another thread could result in a null-pointer dereference due to debugstream transiently being NULL while simple_debug isn't 0. This is largely hypothetical, since it's unlikely anybody uses ECPGdebug() at all in the field, and our own regression tests don't seem to be hitting the theoretical race conditions either. Still, if we're going to the trouble of having mutexes here, we ought to be using them in a way that's actually safe not just almost safe. Hence, back-patch to all supported branches. Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e892e72b3c8ce9221003cddca6b8a88e2c951cad Modified Files -- src/interfaces/ecpg/ecpglib/misc.c | 41 -- 1 file changed, 30 insertions(+), 11 deletions(-)
pgsql: Remove race conditions between ECPGdebug() and ecpg_log().
Remove race conditions between ECPGdebug() and ecpg_log(). Coverity complains that ECPGdebug is accessing debugstream without holding debug_mutex, which is a fair complaint: we should take debug_mutex while changing the settings ecpg_log looks at. In some branches it also complains about unlocked use of simple_debug. I think it's intentional and safe to have a quick unlocked check of simple_debug at the start of ecpg_log, since that early exit will always be taken in non-debug cases. But we should recheck simple_debug after acquiring the mutex. In the worst case, calling ECPGdebug concurrently with ecpg_log in another thread could result in a null-pointer dereference due to debugstream transiently being NULL while simple_debug isn't 0. This is largely hypothetical, since it's unlikely anybody uses ECPGdebug() at all in the field, and our own regression tests don't seem to be hitting the theoretical race conditions either. Still, if we're going to the trouble of having mutexes here, we ought to be using them in a way that's actually safe not just almost safe. Hence, back-patch to all supported branches. Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/cd8f1c1207994c8b3d41c48a02fa40547ee48bea Modified Files -- src/interfaces/ecpg/ecpglib/misc.c | 41 -- 1 file changed, 30 insertions(+), 11 deletions(-)
pgsql: Remove race conditions between ECPGdebug() and ecpg_log().
Remove race conditions between ECPGdebug() and ecpg_log(). Coverity complains that ECPGdebug is accessing debugstream without holding debug_mutex, which is a fair complaint: we should take debug_mutex while changing the settings ecpg_log looks at. In some branches it also complains about unlocked use of simple_debug. I think it's intentional and safe to have a quick unlocked check of simple_debug at the start of ecpg_log, since that early exit will always be taken in non-debug cases. But we should recheck simple_debug after acquiring the mutex. In the worst case, calling ECPGdebug concurrently with ecpg_log in another thread could result in a null-pointer dereference due to debugstream transiently being NULL while simple_debug isn't 0. This is largely hypothetical, since it's unlikely anybody uses ECPGdebug() at all in the field, and our own regression tests don't seem to be hitting the theoretical race conditions either. Still, if we're going to the trouble of having mutexes here, we ought to be using them in a way that's actually safe not just almost safe. Hence, back-patch to all supported branches. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0162a9bde267a0dc88f35a8d286514c059e1e0e2 Modified Files -- src/interfaces/ecpg/ecpglib/misc.c | 39 +++--- 1 file changed, 28 insertions(+), 11 deletions(-)
pgsql: Remove race conditions between ECPGdebug() and ecpg_log().
Remove race conditions between ECPGdebug() and ecpg_log(). Coverity complains that ECPGdebug is accessing debugstream without holding debug_mutex, which is a fair complaint: we should take debug_mutex while changing the settings ecpg_log looks at. In some branches it also complains about unlocked use of simple_debug. I think it's intentional and safe to have a quick unlocked check of simple_debug at the start of ecpg_log, since that early exit will always be taken in non-debug cases. But we should recheck simple_debug after acquiring the mutex. In the worst case, calling ECPGdebug concurrently with ecpg_log in another thread could result in a null-pointer dereference due to debugstream transiently being NULL while simple_debug isn't 0. This is largely hypothetical, since it's unlikely anybody uses ECPGdebug() at all in the field, and our own regression tests don't seem to be hitting the theoretical race conditions either. Still, if we're going to the trouble of having mutexes here, we ought to be using them in a way that's actually safe not just almost safe. Hence, back-patch to all supported branches. Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/78030a66d75b19a6428f30e31b12bc6059c1fff3 Modified Files -- src/interfaces/ecpg/ecpglib/misc.c | 41 -- 1 file changed, 30 insertions(+), 11 deletions(-)
pgsql: Fix input of ISO "extended" time format for types time and timet
Fix input of ISO "extended" time format for types time and timetz. Commit 3e1a373e2 missed teaching DecodeTimeOnly the same "ptype" manipulations it added to DecodeDateTime. While likely harmless at the time, it became a problem after 5b3c59535 added an error check that ptype must be zero once we exit the parsing loop (that is, there shouldn't be any unused prefixes). The consequence was that we'd reject time or timetz input like T12:34:56 (the "extended" format per ISO 8601-1:2019), even though that still worked in timestamp input. Since this is clearly under-tested code, add test cases covering all the ISO 8601 time formats. (Note: although 8601 allows just "Thh", we have never accepted that, and this patch doesn't change that. I'm content to leave that as-is because it seems too likely to be a mistake rather than intended input. If anyone wants to allow that, it should be a separate patch anyway, and not back-patched.) Per bug #18470 from David Perez. Back-patch to v16 where we broke it. Discussion: https://postgr.es/m/18470-34fad4c829106...@postgresql.org Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/019ea7675c7722ff7f9016b878feea8e7faac608 Modified Files -- src/backend/utils/adt/datetime.c | 11 +++ src/test/regress/expected/horology.out | 155 + src/test/regress/sql/horology.sql | 29 ++ 3 files changed, 195 insertions(+)
pgsql: Fix input of ISO "extended" time format for types time and timet
Fix input of ISO "extended" time format for types time and timetz. Commit 3e1a373e2 missed teaching DecodeTimeOnly the same "ptype" manipulations it added to DecodeDateTime. While likely harmless at the time, it became a problem after 5b3c59535 added an error check that ptype must be zero once we exit the parsing loop (that is, there shouldn't be any unused prefixes). The consequence was that we'd reject time or timetz input like T12:34:56 (the "extended" format per ISO 8601-1:2019), even though that still worked in timestamp input. Since this is clearly under-tested code, add test cases covering all the ISO 8601 time formats. (Note: although 8601 allows just "Thh", we have never accepted that, and this patch doesn't change that. I'm content to leave that as-is because it seems too likely to be a mistake rather than intended input. If anyone wants to allow that, it should be a separate patch anyway, and not back-patched.) Per bug #18470 from David Perez. Back-patch to v16 where we broke it. Discussion: https://postgr.es/m/18470-34fad4c829106...@postgresql.org Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a9a7c2c3e15ede7a4f6b44d72a32b105b9113f02 Modified Files -- src/backend/utils/adt/datetime.c | 11 +++ src/test/regress/expected/horology.out | 155 + src/test/regress/sql/horology.sql | 29 ++ 3 files changed, 195 insertions(+)
pgsql: Fix handling of extended expression statistics in CREATE TABLE L
Fix handling of extended expression statistics in CREATE TABLE LIKE. transformTableLikeClause believed that it could process extended statistics immediately because "the representation of CreateStatsStmt doesn't depend on column numbers". That was true when extended stats were first introduced, but it was falsified by the addition of extended stats on expressions: the parsed expression tree is fed forward by the LIKE option, and that will contain Vars. So if the new table doesn't have attnums identical to the old one's (typically because there are some dropped columns in the old one), that doesn't work. The CREATE goes through, but it emits invalid statistics objects that will cause problems later. Fortunately, we already have logic that can adapt expression trees to the possibly-new column numbering. To use it, we have to delay processing of CREATE_TABLE_LIKE_STATISTICS into expandTableLikeClause, just as for other LIKE options that involve expressions. Per bug #18468 from Alexander Lakhin. Back-patch to v14 where extended statistics on expressions were added. Discussion: https://postgr.es/m/18468-f5add190e3fa5...@postgresql.org Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2aa90c02dc6983bf0066bf6df18b713fde916cf7 Modified Files -- src/backend/parser/parse_utilcmd.c | 136 +++- src/test/regress/expected/create_table_like.out | 15 +++ src/test/regress/sql/create_table_like.sql | 8 ++ 3 files changed, 86 insertions(+), 73 deletions(-)
pgsql: Fix handling of extended expression statistics in CREATE TABLE L
Fix handling of extended expression statistics in CREATE TABLE LIKE. transformTableLikeClause believed that it could process extended statistics immediately because "the representation of CreateStatsStmt doesn't depend on column numbers". That was true when extended stats were first introduced, but it was falsified by the addition of extended stats on expressions: the parsed expression tree is fed forward by the LIKE option, and that will contain Vars. So if the new table doesn't have attnums identical to the old one's (typically because there are some dropped columns in the old one), that doesn't work. The CREATE goes through, but it emits invalid statistics objects that will cause problems later. Fortunately, we already have logic that can adapt expression trees to the possibly-new column numbering. To use it, we have to delay processing of CREATE_TABLE_LIKE_STATISTICS into expandTableLikeClause, just as for other LIKE options that involve expressions. Per bug #18468 from Alexander Lakhin. Back-patch to v14 where extended statistics on expressions were added. Discussion: https://postgr.es/m/18468-f5add190e3fa5...@postgresql.org Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2f3cfcf7677ff11ca0ca18b67bd8fc1ea6ae6dd5 Modified Files -- src/backend/parser/parse_utilcmd.c | 136 +++- src/test/regress/expected/create_table_like.out | 15 +++ src/test/regress/sql/create_table_like.sql | 8 ++ 3 files changed, 86 insertions(+), 73 deletions(-)
pgsql: Fix handling of extended expression statistics in CREATE TABLE L
Fix handling of extended expression statistics in CREATE TABLE LIKE. transformTableLikeClause believed that it could process extended statistics immediately because "the representation of CreateStatsStmt doesn't depend on column numbers". That was true when extended stats were first introduced, but it was falsified by the addition of extended stats on expressions: the parsed expression tree is fed forward by the LIKE option, and that will contain Vars. So if the new table doesn't have attnums identical to the old one's (typically because there are some dropped columns in the old one), that doesn't work. The CREATE goes through, but it emits invalid statistics objects that will cause problems later. Fortunately, we already have logic that can adapt expression trees to the possibly-new column numbering. To use it, we have to delay processing of CREATE_TABLE_LIKE_STATISTICS into expandTableLikeClause, just as for other LIKE options that involve expressions. Per bug #18468 from Alexander Lakhin. Back-patch to v14 where extended statistics on expressions were added. Discussion: https://postgr.es/m/18468-f5add190e3fa5...@postgresql.org Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/5278668d7a460d0fac3578d494c039dbc1fc5e89 Modified Files -- src/backend/parser/parse_utilcmd.c | 136 +++- src/test/regress/expected/create_table_like.out | 15 +++ src/test/regress/sql/create_table_like.sql | 8 ++ 3 files changed, 86 insertions(+), 73 deletions(-)
pgsql: Fix handling of extended expression statistics in CREATE TABLE L
Fix handling of extended expression statistics in CREATE TABLE LIKE. transformTableLikeClause believed that it could process extended statistics immediately because "the representation of CreateStatsStmt doesn't depend on column numbers". That was true when extended stats were first introduced, but it was falsified by the addition of extended stats on expressions: the parsed expression tree is fed forward by the LIKE option, and that will contain Vars. So if the new table doesn't have attnums identical to the old one's (typically because there are some dropped columns in the old one), that doesn't work. The CREATE goes through, but it emits invalid statistics objects that will cause problems later. Fortunately, we already have logic that can adapt expression trees to the possibly-new column numbering. To use it, we have to delay processing of CREATE_TABLE_LIKE_STATISTICS into expandTableLikeClause, just as for other LIKE options that involve expressions. Per bug #18468 from Alexander Lakhin. Back-patch to v14 where extended statistics on expressions were added. Discussion: https://postgr.es/m/18468-f5add190e3fa5...@postgresql.org Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1015162c353510854a3c47ad10b78029664ab13a Modified Files -- src/backend/parser/parse_utilcmd.c | 136 +++- src/test/regress/expected/create_table_like.out | 15 +++ src/test/regress/sql/create_table_like.sql | 8 ++ 3 files changed, 86 insertions(+), 73 deletions(-)
pgsql: Stamp 17beta1.
Stamp 17beta1. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/86a2d2a321215797abd1c67d9f2c52510423a97a Modified Files -- configure| 18 +- configure.ac | 2 +- meson.build | 2 +- 3 files changed, 11 insertions(+), 11 deletions(-)
pgsql: Doc: remove 66c0185a3 from release notes.
Doc: remove 66c0185a3 from release notes. Discussion: https://postgr.es/m/zktzf926vslr3...@depesz.com (also some private discussion among pgsql-release) Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e1e83a71715f1c2f0717bb66e630ca3bda79b9c1 Modified Files -- doc/src/sgml/release-17.sgml | 11 --- 1 file changed, 11 deletions(-)
pgsql: Revert commit 66c0185a3 and follow-on patches.
Revert commit 66c0185a3 and follow-on patches. This reverts 66c0185a3 (Allow planner to use Merge Append to efficiently implement UNION) as well as the follow-on commits d5d2205c8, 3b1a7eb28, 7487044d6. In addition to those, 07746a8ef had to be removed then re-applied in a different place, because 66c0185a3 moved the relevant code. The reason for this last-minute thrashing is that depesz found a case in which the patched code creates a completely wrong plan that silently gives incorrect query results. It's unclear what the cause is or how many cases are affected, but with beta1 wrap staring us in the face, there's no time for closer investigation. After we figure that out, we can decide whether to un-revert this for beta2 or hold it for v18. Discussion: https://postgr.es/m/zktzf926vslr3...@depesz.com (also some private discussion among pgsql-release) Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/7204f35919b7e021e8d1bc9f2d76fd6bfcdd2070 Modified Files -- contrib/postgres_fdw/expected/postgres_fdw.out | 7 - contrib/postgres_fdw/sql/postgres_fdw.sql | 9 - src/backend/optimizer/path/allpaths.c | 5 +- src/backend/optimizer/path/equivclass.c| 61 --- src/backend/optimizer/path/pathkeys.c | 19 - src/backend/optimizer/plan/planner.c | 116 +--- src/backend/optimizer/plan/subselect.c | 15 +- src/backend/optimizer/prep/prepunion.c | 720 - src/backend/parser/analyze.c | 3 +- src/include/nodes/pathnodes.h | 2 - src/include/optimizer/paths.h | 4 - src/include/optimizer/planner.h| 3 +- src/include/optimizer/prep.h | 2 +- src/test/regress/expected/collate.icu.utf8.out | 2 - src/test/regress/expected/incremental_sort.out | 13 +- src/test/regress/expected/union.out| 46 +- src/test/regress/sql/collate.icu.utf8.sql | 2 - src/test/regress/sql/union.sql | 19 +- 18 files changed, 287 insertions(+), 761 deletions(-)
pgsql: Account for optimized MinMax aggregates during SS_finalize_plan.
Account for optimized MinMax aggregates during SS_finalize_plan. We are capable of optimizing MIN() and MAX() aggregates on indexed columns into subqueries that exploit the index, rather than the normal thing of scanning the whole table. When we do this, we replace the Aggref node(s) with Params referencing subquery outputs. Such Params really ought to be included in the per-plan-node extParam/allParam sets computed by SS_finalize_plan. However, we've never done so up to now because of an ancient implementation choice to perform that substitution during set_plan_references, which runs after SS_finalize_plan, so that SS_finalize_plan never sees these Params. The cleanest fix would be to perform a separate tree walk to do these substitutions before SS_finalize_plan runs. That seems unattractive, first because a whole-tree mutation pass is expensive, and second because we lack infrastructure for visiting expression subtrees in a Plan tree, so that we'd need a new function knowing as much as SS_finalize_plan knows about that. I also considered swapping the order of SS_finalize_plan and set_plan_references, but that fell foul of various assumptions that seem tricky to fix. So the approach adopted here is to teach SS_finalize_plan itself to check for such Aggrefs. I refactored things a bit in setrefs.c to avoid having three copies of the code that does that. Back-patch of v17 commits d0d44049d and 779ac2c74. When d0d44049d went in, there was no evidence that it was fixing a reachable bug, so I refrained from back-patching. Now we have such evidence. Per bug #18465 from Hal Takahara. Back-patch to all supported branches. Discussion: https://postgr.es/m/18465-2fae927718976...@postgresql.org Discussion: https://postgr.es/m/2391880.1689025...@sss.pgh.pa.us Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5ac340602e7481198f2576567665ce6facc03a89 Modified Files -- src/backend/optimizer/plan/setrefs.c | 68 src/backend/optimizer/plan/subselect.c | 25 ++-- src/include/optimizer/planmain.h | 2 + src/test/regress/expected/aggregates.out | 31 +++ src/test/regress/sql/aggregates.sql | 10 + 5 files changed, 107 insertions(+), 29 deletions(-)
pgsql: Account for optimized MinMax aggregates during SS_finalize_plan.
Account for optimized MinMax aggregates during SS_finalize_plan. We are capable of optimizing MIN() and MAX() aggregates on indexed columns into subqueries that exploit the index, rather than the normal thing of scanning the whole table. When we do this, we replace the Aggref node(s) with Params referencing subquery outputs. Such Params really ought to be included in the per-plan-node extParam/allParam sets computed by SS_finalize_plan. However, we've never done so up to now because of an ancient implementation choice to perform that substitution during set_plan_references, which runs after SS_finalize_plan, so that SS_finalize_plan never sees these Params. The cleanest fix would be to perform a separate tree walk to do these substitutions before SS_finalize_plan runs. That seems unattractive, first because a whole-tree mutation pass is expensive, and second because we lack infrastructure for visiting expression subtrees in a Plan tree, so that we'd need a new function knowing as much as SS_finalize_plan knows about that. I also considered swapping the order of SS_finalize_plan and set_plan_references, but that fell foul of various assumptions that seem tricky to fix. So the approach adopted here is to teach SS_finalize_plan itself to check for such Aggrefs. I refactored things a bit in setrefs.c to avoid having three copies of the code that does that. Back-patch of v17 commits d0d44049d and 779ac2c74. When d0d44049d went in, there was no evidence that it was fixing a reachable bug, so I refrained from back-patching. Now we have such evidence. Per bug #18465 from Hal Takahara. Back-patch to all supported branches. Discussion: https://postgr.es/m/18465-2fae927718976...@postgresql.org Discussion: https://postgr.es/m/2391880.1689025...@sss.pgh.pa.us Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/686c995fc2223426706ee3f2472e220e7aac4041 Modified Files -- src/backend/optimizer/plan/setrefs.c | 68 src/backend/optimizer/plan/subselect.c | 25 ++-- src/include/optimizer/planmain.h | 2 + src/test/regress/expected/aggregates.out | 31 +++ src/test/regress/sql/aggregates.sql | 10 + 5 files changed, 107 insertions(+), 29 deletions(-)
pgsql: Account for optimized MinMax aggregates during SS_finalize_plan.
Account for optimized MinMax aggregates during SS_finalize_plan. We are capable of optimizing MIN() and MAX() aggregates on indexed columns into subqueries that exploit the index, rather than the normal thing of scanning the whole table. When we do this, we replace the Aggref node(s) with Params referencing subquery outputs. Such Params really ought to be included in the per-plan-node extParam/allParam sets computed by SS_finalize_plan. However, we've never done so up to now because of an ancient implementation choice to perform that substitution during set_plan_references, which runs after SS_finalize_plan, so that SS_finalize_plan never sees these Params. The cleanest fix would be to perform a separate tree walk to do these substitutions before SS_finalize_plan runs. That seems unattractive, first because a whole-tree mutation pass is expensive, and second because we lack infrastructure for visiting expression subtrees in a Plan tree, so that we'd need a new function knowing as much as SS_finalize_plan knows about that. I also considered swapping the order of SS_finalize_plan and set_plan_references, but that fell foul of various assumptions that seem tricky to fix. So the approach adopted here is to teach SS_finalize_plan itself to check for such Aggrefs. I refactored things a bit in setrefs.c to avoid having three copies of the code that does that. Back-patch of v17 commits d0d44049d and 779ac2c74. When d0d44049d went in, there was no evidence that it was fixing a reachable bug, so I refrained from back-patching. Now we have such evidence. Per bug #18465 from Hal Takahara. Back-patch to all supported branches. Discussion: https://postgr.es/m/18465-2fae927718976...@postgresql.org Discussion: https://postgr.es/m/2391880.1689025...@sss.pgh.pa.us Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7f90a5dc368620e097fac8690b8698e75f8eccba Modified Files -- src/backend/optimizer/plan/setrefs.c | 68 src/backend/optimizer/plan/subselect.c | 25 ++-- src/include/optimizer/planmain.h | 2 + src/test/regress/expected/aggregates.out | 31 +++ src/test/regress/sql/aggregates.sql | 10 + 5 files changed, 107 insertions(+), 29 deletions(-)
pgsql: Account for optimized MinMax aggregates during SS_finalize_plan.
Account for optimized MinMax aggregates during SS_finalize_plan. We are capable of optimizing MIN() and MAX() aggregates on indexed columns into subqueries that exploit the index, rather than the normal thing of scanning the whole table. When we do this, we replace the Aggref node(s) with Params referencing subquery outputs. Such Params really ought to be included in the per-plan-node extParam/allParam sets computed by SS_finalize_plan. However, we've never done so up to now because of an ancient implementation choice to perform that substitution during set_plan_references, which runs after SS_finalize_plan, so that SS_finalize_plan never sees these Params. The cleanest fix would be to perform a separate tree walk to do these substitutions before SS_finalize_plan runs. That seems unattractive, first because a whole-tree mutation pass is expensive, and second because we lack infrastructure for visiting expression subtrees in a Plan tree, so that we'd need a new function knowing as much as SS_finalize_plan knows about that. I also considered swapping the order of SS_finalize_plan and set_plan_references, but that fell foul of various assumptions that seem tricky to fix. So the approach adopted here is to teach SS_finalize_plan itself to check for such Aggrefs. I refactored things a bit in setrefs.c to avoid having three copies of the code that does that. Back-patch of v17 commits d0d44049d and 779ac2c74. When d0d44049d went in, there was no evidence that it was fixing a reachable bug, so I refrained from back-patching. Now we have such evidence. Per bug #18465 from Hal Takahara. Back-patch to all supported branches. Discussion: https://postgr.es/m/18465-2fae927718976...@postgresql.org Discussion: https://postgr.es/m/2391880.1689025...@sss.pgh.pa.us Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4ac385adc5b7ae6474fc8e8fb418131cf2e63b4b Modified Files -- src/backend/optimizer/plan/setrefs.c | 68 src/backend/optimizer/plan/subselect.c | 25 ++-- src/include/optimizer/planmain.h | 2 + src/test/regress/expected/aggregates.out | 31 +++ src/test/regress/sql/aggregates.sql | 10 + 5 files changed, 107 insertions(+), 29 deletions(-)
pgsql: Account for optimized MinMax aggregates during SS_finalize_plan.
Account for optimized MinMax aggregates during SS_finalize_plan. We are capable of optimizing MIN() and MAX() aggregates on indexed columns into subqueries that exploit the index, rather than the normal thing of scanning the whole table. When we do this, we replace the Aggref node(s) with Params referencing subquery outputs. Such Params really ought to be included in the per-plan-node extParam/allParam sets computed by SS_finalize_plan. However, we've never done so up to now because of an ancient implementation choice to perform that substitution during set_plan_references, which runs after SS_finalize_plan, so that SS_finalize_plan never sees these Params. The cleanest fix would be to perform a separate tree walk to do these substitutions before SS_finalize_plan runs. That seems unattractive, first because a whole-tree mutation pass is expensive, and second because we lack infrastructure for visiting expression subtrees in a Plan tree, so that we'd need a new function knowing as much as SS_finalize_plan knows about that. I also considered swapping the order of SS_finalize_plan and set_plan_references, but that fell foul of various assumptions that seem tricky to fix. So the approach adopted here is to teach SS_finalize_plan itself to check for such Aggrefs. I refactored things a bit in setrefs.c to avoid having three copies of the code that does that. Back-patch of v17 commits d0d44049d and 779ac2c74. When d0d44049d went in, there was no evidence that it was fixing a reachable bug, so I refrained from back-patching. Now we have such evidence. Per bug #18465 from Hal Takahara. Back-patch to all supported branches. Discussion: https://postgr.es/m/18465-2fae927718976...@postgresql.org Discussion: https://postgr.es/m/2391880.1689025...@sss.pgh.pa.us Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ce0d1654463e4f6080cfe83df74ed978945608a1 Modified Files -- src/backend/optimizer/plan/setrefs.c | 68 src/backend/optimizer/plan/subselect.c | 25 ++-- src/include/optimizer/planmain.h | 2 + src/test/regress/expected/aggregates.out | 31 +++ src/test/regress/sql/aggregates.sql | 10 + 5 files changed, 107 insertions(+), 29 deletions(-)
pgsql: Add test case showing that commit d0d44049d fixed a live bug.
Add test case showing that commit d0d44049d fixed a live bug. When I committed d0d44049d (Account for optimized MinMax aggregates during SS_finalize_plan), I didn't have a test case showing that it was fixing any reachable bug. Here is one, based on bug #18465 from Hal Takahara. Without the fix, all rows of the result show the same "min" value, because the aggregate doesn't get recalculated. Committed despite beta1 release freeze, with the concurrence of pgsql-release. Discussion: https://postgr.es/m/18465-2fae927718976...@postgresql.org Discussion: https://postgr.es/m/2391880.1689025...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/779ac2c74bd15744aa92b588f70606a1a95256d2 Modified Files -- src/test/regress/expected/aggregates.out | 31 +++ src/test/regress/sql/aggregates.sql | 10 ++ 2 files changed, 41 insertions(+)
pgsql: Sync typedefs.list with buildfarm, for real this time.
Sync typedefs.list with buildfarm, for real this time. In commit da256a4a7, I manually added some typedef names to the buildfarm-generated list so as not to cause any formatting regressions compared to the prior manually-updated list. About half of the additions were injection-point-related names. It turns out that those were missing because none of the buildfarm animals contributing typedef lists were building with --enable-injection-points. I rectified that on my animal sifaka, and now those are in the list available from the buildfarm. The other half were typedefs that didn't show up in the generated list because our method for collecting that doesn't catch names that are not used to declare any C variables or fields. Such a typedef name doesn't really add a lot of value, so we decided to get rid of them, and that's now been done in commits 110eb4aef and be5942aee. (Note: I'm pretty sure there are some remaining cases of that, but we've already accepted the ensuing odd formatting of the typedef declaration itself. The present fixes only dealt with typedefs that had been manually added to typedefs.list during the v17 development cycle.) Hence, we can now install a verbatim copy of the buildfarm's list and not have it affect anything. The only change is to add InjectionPointCallback, which I'd omitted from da256a4a7 because it chanced not to affect any pgindent decisions. Discussion: https://postgr.es/m/1919000.1715815...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/70353e463cd32ad3368fc1020c3acde5ee9fb476 Modified Files -- src/tools/pgindent/typedefs.list | 1 + 1 file changed, 1 insertion(+)
pgsql: Doc: update src/tools/pgindent/README for current practice.
Doc: update src/tools/pgindent/README for current practice. This README explains how to run pgindent, but it was written for our former practice of running pgindent only infrequently. Nowadays the plan is to keep the tree indent-clean all the time, so the typical thing is to do an incremental pgindent run with each commit. Revise to explain that as the normal case, and the infrequent full-on process as a separate thing. For now, pgperltidy is still a run-it-infrequently item. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/3c03ee1a39c0f808cb261a207b6d465c606598bf Modified Files -- src/tools/pgindent/README | 79 +++ 1 file changed, 45 insertions(+), 34 deletions(-)
pgsql: Fix handling of polymorphic output arguments for procedures.
Fix handling of polymorphic output arguments for procedures. Most of the infrastructure for procedure arguments was already okay with polymorphic output arguments, but it turns out that CallStmtResultDesc() was a few bricks shy of a load here. It thought all it needed to do was call build_function_result_tupdesc_t, but that function specifically disclaims responsibility for resolving polymorphic arguments. Failing to handle that doesn't seem to be a problem for CALL in plpgsql, but CALL from plain SQL would get errors like "cannot display a value of type anyelement", or even crash outright. In v14 and later we can simply examine the exposed types of the CallStmt.outargs nodes to get the right type OIDs. But it's a lot more complicated to fix in v12/v13, because those versions don't have CallStmt.outargs, nor do they do expand_function_arguments until ExecuteCallStmt runs. We have to duplicatively run expand_function_arguments, and then re-determine which elements of the args list are output arguments. Per bug #18463 from Drew Kimball. Back-patch to all supported versions, since it's busted in all of them. Discussion: https://postgr.es/m/18463-f8cd77e12564d...@postgresql.org Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8e0e99972ad92cc128c18bc6af41ef0e4d89e7ae Modified Files -- src/backend/commands/functioncmds.c| 28 + src/pl/plpgsql/src/expected/plpgsql_call.out | 34 ++ src/pl/plpgsql/src/sql/plpgsql_call.sql| 30 +++ src/test/regress/expected/create_procedure.out | 34 ++ src/test/regress/sql/create_procedure.sql | 18 ++ 5 files changed, 144 insertions(+)
pgsql: Fix handling of polymorphic output arguments for procedures.
Fix handling of polymorphic output arguments for procedures. Most of the infrastructure for procedure arguments was already okay with polymorphic output arguments, but it turns out that CallStmtResultDesc() was a few bricks shy of a load here. It thought all it needed to do was call build_function_result_tupdesc_t, but that function specifically disclaims responsibility for resolving polymorphic arguments. Failing to handle that doesn't seem to be a problem for CALL in plpgsql, but CALL from plain SQL would get errors like "cannot display a value of type anyelement", or even crash outright. In v14 and later we can simply examine the exposed types of the CallStmt.outargs nodes to get the right type OIDs. But it's a lot more complicated to fix in v12/v13, because those versions don't have CallStmt.outargs, nor do they do expand_function_arguments until ExecuteCallStmt runs. We have to duplicatively run expand_function_arguments, and then re-determine which elements of the args list are output arguments. Per bug #18463 from Drew Kimball. Back-patch to all supported versions, since it's busted in all of them. Discussion: https://postgr.es/m/18463-f8cd77e12564d...@postgresql.org Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c40e78d239a8f7b8a3b6fd180b6e642e269dec5f Modified Files -- src/backend/commands/functioncmds.c| 28 + src/pl/plpgsql/src/expected/plpgsql_call.out | 34 ++ src/pl/plpgsql/src/sql/plpgsql_call.sql| 30 +++ src/test/regress/expected/create_procedure.out | 34 ++ src/test/regress/sql/create_procedure.sql | 18 ++ 5 files changed, 144 insertions(+)
pgsql: Fix handling of polymorphic output arguments for procedures.
Fix handling of polymorphic output arguments for procedures. Most of the infrastructure for procedure arguments was already okay with polymorphic output arguments, but it turns out that CallStmtResultDesc() was a few bricks shy of a load here. It thought all it needed to do was call build_function_result_tupdesc_t, but that function specifically disclaims responsibility for resolving polymorphic arguments. Failing to handle that doesn't seem to be a problem for CALL in plpgsql, but CALL from plain SQL would get errors like "cannot display a value of type anyelement", or even crash outright. In v14 and later we can simply examine the exposed types of the CallStmt.outargs nodes to get the right type OIDs. But it's a lot more complicated to fix in v12/v13, because those versions don't have CallStmt.outargs, nor do they do expand_function_arguments until ExecuteCallStmt runs. We have to duplicatively run expand_function_arguments, and then re-determine which elements of the args list are output arguments. Per bug #18463 from Drew Kimball. Back-patch to all supported versions, since it's busted in all of them. Discussion: https://postgr.es/m/18463-f8cd77e12564d...@postgresql.org Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f535f350c1f9b5a9c4f10583992576c3af505275 Modified Files -- src/backend/commands/functioncmds.c| 28 + src/pl/plpgsql/src/expected/plpgsql_call.out | 34 ++ src/pl/plpgsql/src/sql/plpgsql_call.sql| 30 +++ src/test/regress/expected/create_procedure.out | 34 ++ src/test/regress/sql/create_procedure.sql | 18 ++ 5 files changed, 144 insertions(+)
pgsql: Fix handling of polymorphic output arguments for procedures.
Fix handling of polymorphic output arguments for procedures. Most of the infrastructure for procedure arguments was already okay with polymorphic output arguments, but it turns out that CallStmtResultDesc() was a few bricks shy of a load here. It thought all it needed to do was call build_function_result_tupdesc_t, but that function specifically disclaims responsibility for resolving polymorphic arguments. Failing to handle that doesn't seem to be a problem for CALL in plpgsql, but CALL from plain SQL would get errors like "cannot display a value of type anyelement", or even crash outright. In v14 and later we can simply examine the exposed types of the CallStmt.outargs nodes to get the right type OIDs. But it's a lot more complicated to fix in v12/v13, because those versions don't have CallStmt.outargs, nor do they do expand_function_arguments until ExecuteCallStmt runs. We have to duplicatively run expand_function_arguments, and then re-determine which elements of the args list are output arguments. Per bug #18463 from Drew Kimball. Back-patch to all supported versions, since it's busted in all of them. Discussion: https://postgr.es/m/18463-f8cd77e12564d...@postgresql.org Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/525bd1620e9ba6b9327cc8ad420ad0352965b2c7 Modified Files -- src/backend/commands/functioncmds.c| 28 + src/pl/plpgsql/src/expected/plpgsql_call.out | 34 ++ src/pl/plpgsql/src/sql/plpgsql_call.sql| 30 +++ src/test/regress/expected/create_procedure.out | 34 ++ src/test/regress/sql/create_procedure.sql | 18 ++ 5 files changed, 144 insertions(+)
pgsql: Fix handling of polymorphic output arguments for procedures.
Fix handling of polymorphic output arguments for procedures. Most of the infrastructure for procedure arguments was already okay with polymorphic output arguments, but it turns out that CallStmtResultDesc() was a few bricks shy of a load here. It thought all it needed to do was call build_function_result_tupdesc_t, but that function specifically disclaims responsibility for resolving polymorphic arguments. Failing to handle that doesn't seem to be a problem for CALL in plpgsql, but CALL from plain SQL would get errors like "cannot display a value of type anyelement", or even crash outright. In v14 and later we can simply examine the exposed types of the CallStmt.outargs nodes to get the right type OIDs. But it's a lot more complicated to fix in v12/v13, because those versions don't have CallStmt.outargs, nor do they do expand_function_arguments until ExecuteCallStmt runs. We have to duplicatively run expand_function_arguments, and then re-determine which elements of the args list are output arguments. Per bug #18463 from Drew Kimball. Back-patch to all supported versions, since it's busted in all of them. Discussion: https://postgr.es/m/18463-f8cd77e12564d...@postgresql.org Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/70ffb27b2349441b6a62b41338ac19aadb619151 Modified Files -- src/backend/commands/functioncmds.c| 73 ++ src/pl/plpgsql/src/expected/plpgsql_call.out | 34 src/pl/plpgsql/src/sql/plpgsql_call.sql| 30 +++ src/test/regress/expected/create_procedure.out | 34 src/test/regress/sql/create_procedure.sql | 18 +++ 5 files changed, 189 insertions(+)
pgsql: Fix handling of polymorphic output arguments for procedures.
Fix handling of polymorphic output arguments for procedures. Most of the infrastructure for procedure arguments was already okay with polymorphic output arguments, but it turns out that CallStmtResultDesc() was a few bricks shy of a load here. It thought all it needed to do was call build_function_result_tupdesc_t, but that function specifically disclaims responsibility for resolving polymorphic arguments. Failing to handle that doesn't seem to be a problem for CALL in plpgsql, but CALL from plain SQL would get errors like "cannot display a value of type anyelement", or even crash outright. In v14 and later we can simply examine the exposed types of the CallStmt.outargs nodes to get the right type OIDs. But it's a lot more complicated to fix in v12/v13, because those versions don't have CallStmt.outargs, nor do they do expand_function_arguments until ExecuteCallStmt runs. We have to duplicatively run expand_function_arguments, and then re-determine which elements of the args list are output arguments. Per bug #18463 from Drew Kimball. Back-patch to all supported versions, since it's busted in all of them. Discussion: https://postgr.es/m/18463-f8cd77e12564d...@postgresql.org Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e85f641b2b527255f1a66bbcce46071da9434c42 Modified Files -- src/backend/commands/functioncmds.c| 73 ++ src/pl/plpgsql/src/expected/plpgsql_call.out | 34 src/pl/plpgsql/src/sql/plpgsql_call.sql| 30 +++ src/test/regress/expected/create_procedure.out | 34 src/test/regress/sql/create_procedure.sql | 18 +++ 5 files changed, 189 insertions(+)
pgsql: Do pre-release housekeeping on catalog data.
Do pre-release housekeeping on catalog data. Run renumber_oids.pl to move high-numbered OIDs down, as per pre-beta tasks specified by RELEASE_CHANGES. For reference, the command was ./renumber_oids.pl --first-mapped-oid 8000 --target-oid 6300 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/245f1cec59d23032d2eab7019e5d836143383452 Modified Files -- src/include/catalog/catversion.h | 2 +- src/include/catalog/pg_authid.dat | 2 +- src/include/catalog/pg_proc.dat | 68 +++ 3 files changed, 36 insertions(+), 36 deletions(-)
pgsql: Add da256a4a7 to .git-blame-ignore-revs.
Add da256a4a7 to .git-blame-ignore-revs. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ce13f54e6055d24e21cc969f498f121c37616921 Modified Files -- .git-blame-ignore-revs | 3 +++ 1 file changed, 3 insertions(+)
pgsql: Pre-beta mechanical code beautification.
Pre-beta mechanical code beautification. Run pgindent, pgperltidy, and reformat-dat-files. The pgindent part of this is pretty small, consisting mainly of fixing up self-inflicted formatting damage from patches that hadn't bothered to add their new typedefs to typedefs.list. In order to keep it from making anything worse, I manually added a dozen or so typedefs that appeared in the existing typedefs.list but not in the buildfarm's list. Perhaps we should formalize that, or better find a way to get those typedefs into the automatic list. pgperltidy is as opinionated as always, and reformat-dat-files too. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/da256a4a7fdcca35fe7ca808686ad3de6ee22306 Modified Files -- contrib/sepgsql/hooks.c| 2 +- contrib/sepgsql/label.c| 2 +- contrib/sepgsql/uavc.c | 2 +- src/backend/catalog/Catalog.pm | 110 +- src/bin/pg_amcheck/t/002_nonesuch.pl | 7 +- src/bin/pg_basebackup/t/010_pg_basebackup.pl | 17 +- src/bin/pg_basebackup/t/040_pg_createsubscriber.pl | 106 +- src/bin/pg_checksums/t/002_actions.pl | 2 +- src/bin/pg_combinebackup/t/002_compare_backups.pl | 69 --- src/bin/pg_combinebackup/t/003_timeline.pl | 16 +- src/bin/pg_combinebackup/t/004_manifest.pl | 26 +-- src/bin/pg_combinebackup/t/005_integrity.pl| 45 +++-- src/bin/pg_combinebackup/t/006_db_file_copy.pl | 20 +- src/bin/pg_dump/t/002_pg_dump.pl | 14 +- src/bin/pg_rewind/t/003_extrafiles.pl | 4 +- src/bin/pg_upgrade/check.c | 224 ++--- src/bin/pg_upgrade/t/003_logical_slots.pl | 5 +- src/bin/pg_upgrade/t/004_subscription.pl | 3 +- src/bin/pg_verifybackup/t/003_corruption.pl| 8 +- src/bin/pg_verifybackup/t/005_bad_manifest.pl | 3 +- src/bin/pg_waldump/t/001_basic.pl | 151 ++ src/bin/pg_walsummary/t/002_blocks.pl | 10 +- src/bin/pgbench/t/001_pgbench_with_server.pl | 9 +- src/bin/psql/t/001_basic.pl| 16 +- src/bin/scripts/t/011_clusterdb_all.pl | 9 +- src/bin/scripts/t/050_dropdb.pl| 2 +- src/bin/scripts/t/091_reindexdb_all.pl | 9 +- src/bin/scripts/t/100_vacuumdb.pl | 5 +- src/bin/scripts/t/101_vacuumdb_all.pl | 9 +- src/common/jsonapi.c | 42 ++-- src/common/unicode_case.c | 10 +- src/common/unicode_category.c | 4 +- src/include/catalog/pg_aggregate.dat | 14 +- src/include/catalog/pg_collation.dat | 3 +- src/include/catalog/pg_database.dat| 6 +- src/include/catalog/pg_proc.dat| 81 src/include/catalog/pg_type.dat| 9 +- src/include/common/unicode_case_table.h| 4 +- src/include/common/unicode_category_table.h| 6 +- src/interfaces/libpq/t/005_negotiate_encryption.pl | 180 +++-- src/port/pg_popcount_avx512.c | 2 +- src/test/modules/test_pg_dump/t/001_base.pl| 12 +- src/test/modules/test_radixtree/test_radixtree.c | 8 +- src/test/perl/PostgreSQL/Test/Cluster.pm | 50 ++--- src/test/perl/PostgreSQL/Test/Kerberos.pm | 19 +- src/test/recovery/t/001_stream_rep.pl | 8 +- src/test/recovery/t/015_promotion_pages.pl | 3 +- src/test/recovery/t/019_replslot_limit.pl | 4 +- .../recovery/t/035_standby_logical_decoding.pl | 9 +- src/test/recovery/t/037_invalid_database.pl| 10 +- .../recovery/t/040_standby_failover_slots_sync.pl | 92 + src/test/ssl/t/001_ssltests.pl | 3 +- src/test/subscription/t/008_diff_schema.pl | 3 +- .../subscription/t/019_stream_subxact_ddl_abort.pl | 3 +- src/test/subscription/t/026_stats.pl | 3 +- src/test/subscription/t/029_on_error.pl| 3 +- src/test/subscription/t/032_subscribe_use_index.pl | 3 +- src/test/subscription/t/033_run_as_table_owner.pl | 5 +- src/test/subscription/t/100_bugs.pl| 15 +- src/tools/pgindent/typedefs.list | 143 - 60 files changed, 971 insertions(+), 691 deletions(-)
pgsql: Remove COMMAND_TAG_NEXTTAG from enum CommandTag.
Remove COMMAND_TAG_NEXTTAG from enum CommandTag. COMMAND_TAG_NEXTTAG isn't really a valid command tag. Declaring it as if it were one prompts complaints from Coverity and perhaps other static analyzers. Our only use of it is in an entirely-unnecessary array sizing declaration, so let's just drop it. Ranier Vilela Discussion: https://postgr.es/m/caeudqaoy0xrkutax7w10zsjjupkbpfrtdcyscb3z0fb2v6h...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/1f7452fa598ee5f1ed32f1fcce101c63c6f1933f Modified Files -- src/backend/tcop/cmdtag.c | 2 +- src/include/tcop/cmdtag.h | 1 - 2 files changed, 1 insertion(+), 2 deletions(-)
pgsql: Doc: update the "Using EXPLAIN" examples to match current code.
Doc: update the "Using EXPLAIN" examples to match current code. A lot of the examples in this section are quite ancient and no longer match the system's current behavior. I ran through them and updated the sample output to match what I get today. Notably, it seems that the tenk1 table got a few pages smaller back around v12, so that a lot of the cost estimates for queries on that table are a little different now. (This also caused some examples to surprisingly not match others, depending on when they were made.) One mergejoin-based example no longer produces the same plan at all, so I had to work around that, including switching to a different example of using an enable_xxx setting. I also changed a couple of examples that were relying on nonexistent tables or indexes. IMO the premise of this section is that the examples should be more-or-less reproducible against the regression database, so that these examples were unhelpful as given. It's not that hard to find a corresponding example with the tables we do have. Some of the EXPLAIN ANALYZE examples were out of date in that we show more numbers than we did at the time. Possibly chapter 68 could use similar review, but I'm out of energy for today. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/5caa0574963c75cfe7745b1b05f1fd51e3fdf16e Modified Files -- doc/src/sgml/perform.sgml | 280 +- 1 file changed, 150 insertions(+), 130 deletions(-)
pgsql: Last-minute updates for release notes.
Last-minute updates for release notes. Security: CVE-2024-4317 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7b2ac0f6039f0f64d80c7488f0f718094cfb89a2 Modified Files -- doc/src/sgml/release-15.sgml | 95 +++- 1 file changed, 94 insertions(+), 1 deletion(-)
pgsql: Last-minute updates for release notes.
Last-minute updates for release notes. Security: CVE-2024-4317 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a62be834aeb899dfc2e10e3cde6d0f48ba128373 Modified Files -- doc/src/sgml/release-16.sgml | 95 +++- 1 file changed, 94 insertions(+), 1 deletion(-)
pgsql: Last-minute updates for release notes.
Last-minute updates for release notes. Security: CVE-2024-4317 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b7712704f0bb3dc82f286516a7057b0fa5b1d260 Modified Files -- doc/src/sgml/release-14.sgml | 95 +++- 1 file changed, 94 insertions(+), 1 deletion(-)
pgsql: Fix recursive RECORD-returning plpython functions.
Fix recursive RECORD-returning plpython functions. If we recursed to a new call of the same function, with a different coldeflist (AS clause), it would fail because the inner call would overwrite the outer call's idea of what to return. This is vaguely like 1d2fe56e4 and c5bec5426, but it's not due to any API decisions: it's just that we computed the actual output rowtype at the start of the call, and saved it in the per-procedure data structure. We can fix it at basically zero cost by doing the computation at the end of each call instead of the start. It's not clear that there's any real-world use-case for such a function, but given that it doesn't cost anything to fix, it'd be silly not to. Per report from Andreas Karlsson. Back-patch to all supported branches. Discussion: https://postgr.es/m/1651a46d-3c15-4028-a8c1-d74937b54...@proxel.se Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/157b1e6b41b4a1f4bdb3166c791bb3a103abd8c4 Modified Files -- src/pl/plpython/expected/plpython_composite.out | 14 +++ src/pl/plpython/plpy_exec.c | 33 + src/pl/plpython/sql/plpython_composite.sql | 11 + 3 files changed, 42 insertions(+), 16 deletions(-)
pgsql: Fix recursive RECORD-returning plpython functions.
Fix recursive RECORD-returning plpython functions. If we recursed to a new call of the same function, with a different coldeflist (AS clause), it would fail because the inner call would overwrite the outer call's idea of what to return. This is vaguely like 1d2fe56e4 and c5bec5426, but it's not due to any API decisions: it's just that we computed the actual output rowtype at the start of the call, and saved it in the per-procedure data structure. We can fix it at basically zero cost by doing the computation at the end of each call instead of the start. It's not clear that there's any real-world use-case for such a function, but given that it doesn't cost anything to fix, it'd be silly not to. Per report from Andreas Karlsson. Back-patch to all supported branches. Discussion: https://postgr.es/m/1651a46d-3c15-4028-a8c1-d74937b54...@proxel.se Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2728677923d2a025575dee4a24580e3e899c5615 Modified Files -- src/pl/plpython/expected/plpython_composite.out | 14 +++ src/pl/plpython/plpy_exec.c | 33 + src/pl/plpython/sql/plpython_composite.sql | 11 + 3 files changed, 42 insertions(+), 16 deletions(-)
pgsql: Fix recursive RECORD-returning plpython functions.
Fix recursive RECORD-returning plpython functions. If we recursed to a new call of the same function, with a different coldeflist (AS clause), it would fail because the inner call would overwrite the outer call's idea of what to return. This is vaguely like 1d2fe56e4 and c5bec5426, but it's not due to any API decisions: it's just that we computed the actual output rowtype at the start of the call, and saved it in the per-procedure data structure. We can fix it at basically zero cost by doing the computation at the end of each call instead of the start. It's not clear that there's any real-world use-case for such a function, but given that it doesn't cost anything to fix, it'd be silly not to. Per report from Andreas Karlsson. Back-patch to all supported branches. Discussion: https://postgr.es/m/1651a46d-3c15-4028-a8c1-d74937b54...@proxel.se Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d727c543176c32205372991d3e036e5349fb719d Modified Files -- src/pl/plpython/expected/plpython_composite.out | 14 +++ src/pl/plpython/plpy_exec.c | 33 + src/pl/plpython/sql/plpython_composite.sql | 11 + 3 files changed, 42 insertions(+), 16 deletions(-)
pgsql: Fix recursive RECORD-returning plpython functions.
Fix recursive RECORD-returning plpython functions. If we recursed to a new call of the same function, with a different coldeflist (AS clause), it would fail because the inner call would overwrite the outer call's idea of what to return. This is vaguely like 1d2fe56e4 and c5bec5426, but it's not due to any API decisions: it's just that we computed the actual output rowtype at the start of the call, and saved it in the per-procedure data structure. We can fix it at basically zero cost by doing the computation at the end of each call instead of the start. It's not clear that there's any real-world use-case for such a function, but given that it doesn't cost anything to fix, it'd be silly not to. Per report from Andreas Karlsson. Back-patch to all supported branches. Discussion: https://postgr.es/m/1651a46d-3c15-4028-a8c1-d74937b54...@proxel.se Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/52ea653aa9d867be70b2d86fe8310dde48507b6a Modified Files -- src/pl/plpython/expected/plpython_composite.out | 14 +++ src/pl/plpython/plpy_exec.c | 33 + src/pl/plpython/sql/plpython_composite.sql | 11 + 3 files changed, 42 insertions(+), 16 deletions(-)
pgsql: Fix recursive RECORD-returning plpython functions.
Fix recursive RECORD-returning plpython functions. If we recursed to a new call of the same function, with a different coldeflist (AS clause), it would fail because the inner call would overwrite the outer call's idea of what to return. This is vaguely like 1d2fe56e4 and c5bec5426, but it's not due to any API decisions: it's just that we computed the actual output rowtype at the start of the call, and saved it in the per-procedure data structure. We can fix it at basically zero cost by doing the computation at the end of each call instead of the start. It's not clear that there's any real-world use-case for such a function, but given that it doesn't cost anything to fix, it'd be silly not to. Per report from Andreas Karlsson. Back-patch to all supported branches. Discussion: https://postgr.es/m/1651a46d-3c15-4028-a8c1-d74937b54...@proxel.se Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d39337021e12d569e3241a605120f010f77b9e22 Modified Files -- src/pl/plpython/expected/plpython_composite.out | 14 +++ src/pl/plpython/plpy_exec.c | 33 + src/pl/plpython/sql/plpython_composite.sql | 11 + 3 files changed, 42 insertions(+), 16 deletions(-)
pgsql: Fix recursive RECORD-returning plpython functions.
Fix recursive RECORD-returning plpython functions. If we recursed to a new call of the same function, with a different coldeflist (AS clause), it would fail because the inner call would overwrite the outer call's idea of what to return. This is vaguely like 1d2fe56e4 and c5bec5426, but it's not due to any API decisions: it's just that we computed the actual output rowtype at the start of the call, and saved it in the per-procedure data structure. We can fix it at basically zero cost by doing the computation at the end of each call instead of the start. It's not clear that there's any real-world use-case for such a function, but given that it doesn't cost anything to fix, it'd be silly not to. Per report from Andreas Karlsson. Back-patch to all supported branches. Discussion: https://postgr.es/m/1651a46d-3c15-4028-a8c1-d74937b54...@proxel.se Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/6e29963edd55cfc038304322049d8fe697580f2c Modified Files -- src/pl/plpython/expected/plpython_composite.out | 14 +++ src/pl/plpython/plpy_exec.c | 33 + src/pl/plpython/sql/plpython_composite.sql | 11 + 3 files changed, 42 insertions(+), 16 deletions(-)
pgsql: Repair ALTER EXTENSION ... SET SCHEMA.
Repair ALTER EXTENSION ... SET SCHEMA. It turns out that we broke this in commit e5bc9454e, because the code was assuming that no dependent types would appear among the extension's direct dependencies, and now they do. This isn't terribly hard to fix: just skip dependent types, expecting that we will recurse to them when we process the parent object (which should also be among the direct dependencies). But a little bit of refactoring is needed so that we can avoid duplicating logic about what is a dependent type. Although there is some testing of ALTER EXTENSION SET SCHEMA, it failed to cover interesting cases, so add more tests. Discussion: https://postgr.es/m/930191.1715205...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/9effc4608e1f6d19546a0e0f64320f4b0dd10c3c Modified Files -- src/backend/commands/alter.c | 14 ++--- src/backend/commands/extension.c | 2 +- src/backend/commands/tablecmds.c | 7 ++- src/backend/commands/typecmds.c| 69 +- src/include/commands/typecmds.h| 4 +- src/test/modules/test_extensions/Makefile | 2 + .../test_extensions/expected/test_extensions.out | 38 src/test/modules/test_extensions/meson.build | 2 + .../test_extensions/sql/test_extensions.sql| 10 .../test_extensions/test_ext_set_schema--1.0.sql | 17 ++ .../test_extensions/test_ext_set_schema.control| 3 + 11 files changed, 141 insertions(+), 27 deletions(-)
pgsql: Make left-join removal safe under -DREALLOCATE_BITMAPSETS.
Make left-join removal safe under -DREALLOCATE_BITMAPSETS. The initial building of RestrictInfos and SpecialJoinInfos tends to create structures that share relid sets (such as syn_lefthand and outer_relids). There's nothing wrong with that in itself, but when we modify those relid sets during join removal, we have to be sure not to corrupt the values that other structures are pointing at. remove_rel_from_query() was careless about this. It accidentally worked anyway because (1) we'd never be reducing the sets to empty, so they wouldn't get pfree'd; and (2) the in-place modification is the same one that we did or will apply to the other struct's relid set, so that there wasn't visible corruption at the end of the process. While there's no live bug in a standard build, of course this is way too fragile to accept going forward. (Maybe we should back-patch this change too for safety, but I've refrained for now.) This bug was exposed by the recent invention of REALLOCATE_BITMAPSETS. Commit e0477837c had installed a fix, but that went away with the reversion of SJE, so now we need to fix it again. David Rowley and Tom Lane Discussion: https://postgr.es/m/CACJufxFVQmr4=jwhaosluka5zy9h26ny6tvrrfboekhoaly...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c7be3c015bfe518d0624029e640252248a3c8615 Modified Files -- src/backend/optimizer/plan/analyzejoins.c | 18 -- 1 file changed, 16 insertions(+), 2 deletions(-)
pgsql: Doc: document that triggers can break referential integrity.
Doc: document that triggers can break referential integrity. User-written triggers can modify or block the effects of SQL update and delete operations. That includes operations that are executed to implement foreign keys' referential integrity actions (such as ON UPDATE SET NULL or ON DELETE CASCADE). Therefore it's possible for a misdesigned trigger to result in a database state that violates the foreign key constraint. While this isn't great, the alternatives seem worse: in particular, refusing to fire triggers for such updates would break many valuable use-cases. We could also try to recheck the constraint after the action, but that'd roughly double the already-high cost of FK constraint enforcement, for no benefit in normal cases. So we've always considered that it's on the trigger programmer's head to avoid breaking RI actions. This was never documented anywhere, though. Add a para to the Triggers chapter to explain it. Laurenz Albe, David Johnston, Tom Lane Discussion: https://postgr.es/m/b81fe38fcc25a81be6e2e5b3fc1ff624130762fa.ca...@cybertec.at Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/2fb7560cc8f8ba72fab840e7ae2b2b8c36e68c53 Modified Files -- doc/src/sgml/trigger.sgml | 11 +++ 1 file changed, 11 insertions(+)
pgsql: Ensure that "pg_restore -l" reports dependent TOC entries correc
Ensure that "pg_restore -l" reports dependent TOC entries correctly. If -l was specified together with selective-restore options such as -n or -N, dependent TOC entries such as comments would be omitted from the listing, even when an actual restore would have selected them. This happened because PrintTOCSummary neglected to update the te->reqs marking of the entry they depended on. Per report from Justin Pryzby. This has been wrong since 0d4e6ed30 taught _tocEntryRequired to sometimes look at the "reqs" marking of other TOC entries, so back-patch to all supported branches. Discussion: https://postgr.es/m/ZjoeirG7yxODdC4P@pryzbyj2023 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c1aea206e3e333b8c9f8be20422426ae845dd0cf Modified Files -- src/bin/pg_dump/pg_backup_archiver.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-)
pgsql: Ensure that "pg_restore -l" reports dependent TOC entries correc
Ensure that "pg_restore -l" reports dependent TOC entries correctly. If -l was specified together with selective-restore options such as -n or -N, dependent TOC entries such as comments would be omitted from the listing, even when an actual restore would have selected them. This happened because PrintTOCSummary neglected to update the te->reqs marking of the entry they depended on. Per report from Justin Pryzby. This has been wrong since 0d4e6ed30 taught _tocEntryRequired to sometimes look at the "reqs" marking of other TOC entries, so back-patch to all supported branches. Discussion: https://postgr.es/m/ZjoeirG7yxODdC4P@pryzbyj2023 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a3c00ab1545029ee5d8c87d55da976ae1ccf2ba8 Modified Files -- src/bin/pg_dump/pg_backup_archiver.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-)
pgsql: Ensure that "pg_restore -l" reports dependent TOC entries correc
Ensure that "pg_restore -l" reports dependent TOC entries correctly. If -l was specified together with selective-restore options such as -n or -N, dependent TOC entries such as comments would be omitted from the listing, even when an actual restore would have selected them. This happened because PrintTOCSummary neglected to update the te->reqs marking of the entry they depended on. Per report from Justin Pryzby. This has been wrong since 0d4e6ed30 taught _tocEntryRequired to sometimes look at the "reqs" marking of other TOC entries, so back-patch to all supported branches. Discussion: https://postgr.es/m/ZjoeirG7yxODdC4P@pryzbyj2023 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/6a458d93ba5f8d4b12db6a78d31ba2623e9cb594 Modified Files -- src/bin/pg_dump/pg_backup_archiver.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-)
pgsql: Ensure that "pg_restore -l" reports dependent TOC entries correc
Ensure that "pg_restore -l" reports dependent TOC entries correctly. If -l was specified together with selective-restore options such as -n or -N, dependent TOC entries such as comments would be omitted from the listing, even when an actual restore would have selected them. This happened because PrintTOCSummary neglected to update the te->reqs marking of the entry they depended on. Per report from Justin Pryzby. This has been wrong since 0d4e6ed30 taught _tocEntryRequired to sometimes look at the "reqs" marking of other TOC entries, so back-patch to all supported branches. Discussion: https://postgr.es/m/ZjoeirG7yxODdC4P@pryzbyj2023 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/52b23b4e1c6f703a6617c027a5def99772af4ce4 Modified Files -- src/bin/pg_dump/pg_backup_archiver.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-)
pgsql: Ensure that "pg_restore -l" reports dependent TOC entries correc
Ensure that "pg_restore -l" reports dependent TOC entries correctly. If -l was specified together with selective-restore options such as -n or -N, dependent TOC entries such as comments would be omitted from the listing, even when an actual restore would have selected them. This happened because PrintTOCSummary neglected to update the te->reqs marking of the entry they depended on. Per report from Justin Pryzby. This has been wrong since 0d4e6ed30 taught _tocEntryRequired to sometimes look at the "reqs" marking of other TOC entries, so back-patch to all supported branches. Discussion: https://postgr.es/m/ZjoeirG7yxODdC4P@pryzbyj2023 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b99dc6694ca64d8e5bd5ee2b0c6bdbbb8cdf4c99 Modified Files -- src/bin/pg_dump/pg_backup_archiver.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-)
pgsql: Ensure that "pg_restore -l" reports dependent TOC entries correc
Ensure that "pg_restore -l" reports dependent TOC entries correctly. If -l was specified together with selective-restore options such as -n or -N, dependent TOC entries such as comments would be omitted from the listing, even when an actual restore would have selected them. This happened because PrintTOCSummary neglected to update the te->reqs marking of the entry they depended on. Per report from Justin Pryzby. This has been wrong since 0d4e6ed30 taught _tocEntryRequired to sometimes look at the "reqs" marking of other TOC entries, so back-patch to all supported branches. Discussion: https://postgr.es/m/ZjoeirG7yxODdC4P@pryzbyj2023 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5dce8ce0ac48bc8af33d7efcdbfee713781598ed Modified Files -- src/bin/pg_dump/pg_backup_archiver.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-)
pgsql: Don't corrupt plpython's "TD" dictionary in a recursive trigger
Don't corrupt plpython's "TD" dictionary in a recursive trigger call. If a plpython-language trigger caused another one to be invoked, the "TD" dictionary created for the inner one would overwrite the outer one's "TD" dictionary. This is more or less the same problem that 1d2fe56e4 fixed for ordinary functions in plpython, so fix it the same way, by saving and restoring "TD" during a recursive invocation. This fix makes an ABI-incompatible change in struct PLySavedArgs. I'm not too worried about that because it seems highly unlikely that any extension is messing with those structs. We could imagine doing something weird to preserve nominal ABI compatibility in the back branches, like keeping the saved TD object in an extra element of namedargs[]. However, that would only be very nominal compatibility: if anything *is* touching PLySavedArgs, it would likely do the wrong thing due to not knowing about the additional value. So I judge it not worth the ugliness to do something different there. (I also changed struct PLyProcedure, but its added field fits into formerly-padding space, so that should be safe.) Per bug #18456 from Jacques Combrink. This bug is very ancient, so back-patch to all supported branches. Discussion: https://postgr.es/m/3008982.1714853...@sss.pgh.pa.us Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4488142a463c623d3567b1452deb6d768cd0ee9b Modified Files -- src/pl/plpython/expected/plpython_trigger.out | 27 src/pl/plpython/plpy_exec.c | 30 --- src/pl/plpython/plpy_procedure.c | 1 + src/pl/plpython/plpy_procedure.h | 2 ++ src/pl/plpython/sql/plpython_trigger.sql | 24 + 5 files changed, 81 insertions(+), 3 deletions(-)
pgsql: Don't corrupt plpython's "TD" dictionary in a recursive trigger
Don't corrupt plpython's "TD" dictionary in a recursive trigger call. If a plpython-language trigger caused another one to be invoked, the "TD" dictionary created for the inner one would overwrite the outer one's "TD" dictionary. This is more or less the same problem that 1d2fe56e4 fixed for ordinary functions in plpython, so fix it the same way, by saving and restoring "TD" during a recursive invocation. This fix makes an ABI-incompatible change in struct PLySavedArgs. I'm not too worried about that because it seems highly unlikely that any extension is messing with those structs. We could imagine doing something weird to preserve nominal ABI compatibility in the back branches, like keeping the saved TD object in an extra element of namedargs[]. However, that would only be very nominal compatibility: if anything *is* touching PLySavedArgs, it would likely do the wrong thing due to not knowing about the additional value. So I judge it not worth the ugliness to do something different there. (I also changed struct PLyProcedure, but its added field fits into formerly-padding space, so that should be safe.) Per bug #18456 from Jacques Combrink. This bug is very ancient, so back-patch to all supported branches. Discussion: https://postgr.es/m/3008982.1714853...@sss.pgh.pa.us Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/abe60b6a0d276a073fc3f057498a920cdab906a9 Modified Files -- src/pl/plpython/expected/plpython_trigger.out | 27 + src/pl/plpython/plpy_exec.c | 29 --- src/pl/plpython/plpy_procedure.c | 1 + src/pl/plpython/plpy_procedure.h | 2 ++ src/pl/plpython/sql/plpython_trigger.sql | 24 ++ 5 files changed, 80 insertions(+), 3 deletions(-)
pgsql: Don't corrupt plpython's "TD" dictionary in a recursive trigger
Don't corrupt plpython's "TD" dictionary in a recursive trigger call. If a plpython-language trigger caused another one to be invoked, the "TD" dictionary created for the inner one would overwrite the outer one's "TD" dictionary. This is more or less the same problem that 1d2fe56e4 fixed for ordinary functions in plpython, so fix it the same way, by saving and restoring "TD" during a recursive invocation. This fix makes an ABI-incompatible change in struct PLySavedArgs. I'm not too worried about that because it seems highly unlikely that any extension is messing with those structs. We could imagine doing something weird to preserve nominal ABI compatibility in the back branches, like keeping the saved TD object in an extra element of namedargs[]. However, that would only be very nominal compatibility: if anything *is* touching PLySavedArgs, it would likely do the wrong thing due to not knowing about the additional value. So I judge it not worth the ugliness to do something different there. (I also changed struct PLyProcedure, but its added field fits into formerly-padding space, so that should be safe.) Per bug #18456 from Jacques Combrink. This bug is very ancient, so back-patch to all supported branches. Discussion: https://postgr.es/m/3008982.1714853...@sss.pgh.pa.us Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/363e8c2f98b80e039873902b3b3fd003ae09bd9e Modified Files -- src/pl/plpython/expected/plpython_trigger.out | 27 + src/pl/plpython/plpy_exec.c | 29 --- src/pl/plpython/plpy_procedure.c | 1 + src/pl/plpython/plpy_procedure.h | 2 ++ src/pl/plpython/sql/plpython_trigger.sql | 24 ++ 5 files changed, 80 insertions(+), 3 deletions(-)
pgsql: Don't corrupt plpython's "TD" dictionary in a recursive trigger
Don't corrupt plpython's "TD" dictionary in a recursive trigger call. If a plpython-language trigger caused another one to be invoked, the "TD" dictionary created for the inner one would overwrite the outer one's "TD" dictionary. This is more or less the same problem that 1d2fe56e4 fixed for ordinary functions in plpython, so fix it the same way, by saving and restoring "TD" during a recursive invocation. This fix makes an ABI-incompatible change in struct PLySavedArgs. I'm not too worried about that because it seems highly unlikely that any extension is messing with those structs. We could imagine doing something weird to preserve nominal ABI compatibility in the back branches, like keeping the saved TD object in an extra element of namedargs[]. However, that would only be very nominal compatibility: if anything *is* touching PLySavedArgs, it would likely do the wrong thing due to not knowing about the additional value. So I judge it not worth the ugliness to do something different there. (I also changed struct PLyProcedure, but its added field fits into formerly-padding space, so that should be safe.) Per bug #18456 from Jacques Combrink. This bug is very ancient, so back-patch to all supported branches. Discussion: https://postgr.es/m/3008982.1714853...@sss.pgh.pa.us Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/be18a12b663181f304d49022a452e31e4df42ff2 Modified Files -- src/pl/plpython/expected/plpython_trigger.out | 27 + src/pl/plpython/plpy_exec.c | 29 --- src/pl/plpython/plpy_procedure.c | 1 + src/pl/plpython/plpy_procedure.h | 2 ++ src/pl/plpython/sql/plpython_trigger.sql | 24 ++ 5 files changed, 80 insertions(+), 3 deletions(-)
pgsql: Don't corrupt plpython's "TD" dictionary in a recursive trigger
Don't corrupt plpython's "TD" dictionary in a recursive trigger call. If a plpython-language trigger caused another one to be invoked, the "TD" dictionary created for the inner one would overwrite the outer one's "TD" dictionary. This is more or less the same problem that 1d2fe56e4 fixed for ordinary functions in plpython, so fix it the same way, by saving and restoring "TD" during a recursive invocation. This fix makes an ABI-incompatible change in struct PLySavedArgs. I'm not too worried about that because it seems highly unlikely that any extension is messing with those structs. We could imagine doing something weird to preserve nominal ABI compatibility in the back branches, like keeping the saved TD object in an extra element of namedargs[]. However, that would only be very nominal compatibility: if anything *is* touching PLySavedArgs, it would likely do the wrong thing due to not knowing about the additional value. So I judge it not worth the ugliness to do something different there. (I also changed struct PLyProcedure, but its added field fits into formerly-padding space, so that should be safe.) Per bug #18456 from Jacques Combrink. This bug is very ancient, so back-patch to all supported branches. Discussion: https://postgr.es/m/3008982.1714853...@sss.pgh.pa.us Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/90d39929a8900ba38a3ded503481867ca3182849 Modified Files -- src/pl/plpython/expected/plpython_trigger.out | 27 + src/pl/plpython/plpy_exec.c | 29 --- src/pl/plpython/plpy_procedure.c | 1 + src/pl/plpython/plpy_procedure.h | 2 ++ src/pl/plpython/sql/plpython_trigger.sql | 24 ++ 5 files changed, 80 insertions(+), 3 deletions(-)
pgsql: Don't corrupt plpython's "TD" dictionary in a recursive trigger
Don't corrupt plpython's "TD" dictionary in a recursive trigger call. If a plpython-language trigger caused another one to be invoked, the "TD" dictionary created for the inner one would overwrite the outer one's "TD" dictionary. This is more or less the same problem that 1d2fe56e4 fixed for ordinary functions in plpython, so fix it the same way, by saving and restoring "TD" during a recursive invocation. This fix makes an ABI-incompatible change in struct PLySavedArgs. I'm not too worried about that because it seems highly unlikely that any extension is messing with those structs. We could imagine doing something weird to preserve nominal ABI compatibility in the back branches, like keeping the saved TD object in an extra element of namedargs[]. However, that would only be very nominal compatibility: if anything *is* touching PLySavedArgs, it would likely do the wrong thing due to not knowing about the additional value. So I judge it not worth the ugliness to do something different there. (I also changed struct PLyProcedure, but its added field fits into formerly-padding space, so that should be safe.) Per bug #18456 from Jacques Combrink. This bug is very ancient, so back-patch to all supported branches. Discussion: https://postgr.es/m/3008982.1714853...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c5bec5426af989f2a9b0c1f4b97340798fe153f7 Modified Files -- src/pl/plpython/expected/plpython_trigger.out | 27 + src/pl/plpython/plpy_exec.c | 29 --- src/pl/plpython/plpy_procedure.c | 1 + src/pl/plpython/plpy_procedure.h | 2 ++ src/pl/plpython/sql/plpython_trigger.sql | 24 ++ 5 files changed, 80 insertions(+), 3 deletions(-)
pgsql: Prevent RLS filters on ctid from breaking WHERE CURRENT OF
Prevent RLS filters on ctid from breaking WHERE CURRENT OF . The executor only supports CurrentOfExpr as the sole tidqual of a TidScan plan node. tidpath.c failed to take any particular care about that, but would just take the first ctid equality qual it could find in the target relation's baserestrictinfo list. Originally that was fine because the grammar prevents any other WHERE conditions from being combined with CURRENT OF . However, if the relation has RLS visibility policies then those would get included in the list. Should such a policy include a condition on ctid, we'd typically grab the wrong qual and produce a malfunctioning plan. To fix, introduce a simplistic priority ordering scheme for which ctid equality qual to prefer. Real-world cases involving more than one such qual are so rare that it doesn't seem worth going to any great trouble to choose one over another, so I didn't work very hard; but this code could be extended in future if someone thinks differently. It's extremely difficult to think of a reasonable use-case for an RLS restriction involving ctid, and certainly we've heard no field reports of this failure. So this doesn't seem worthy of back-patching, but in the name of cleanliness let's fix it going forward. Patch by me, per report from Robert Haas. Discussion: https://postgr.es/m/3914881.1715038...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6572bd55b0a63fe234ec454e7a13f3a373864e9e Modified Files -- src/backend/optimizer/path/tidpath.c | 88 --- src/test/regress/expected/rowsecurity.out | 41 ++ src/test/regress/sql/rowsecurity.sql | 19 +++ 3 files changed, 118 insertions(+), 30 deletions(-)
pgsql: Stamp 12.19.
Stamp 12.19. Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/01aeb431c12a3388594a445ca97e71cbed410ed2 Modified Files -- configure| 18 +- configure.in | 2 +- src/include/pg_config.h.win32| 8 src/interfaces/libpq/libpq.rc.in | 8 src/port/win32ver.rc | 4 ++-- 5 files changed, 20 insertions(+), 20 deletions(-)
pgsql: Stamp 13.15.
Stamp 13.15. Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8e5faba4b918ba6142339c8f55eaa4eb99776a03 Modified Files -- configure| 18 +- configure.in | 2 +- 2 files changed, 10 insertions(+), 10 deletions(-)
pgsql: Stamp 14.12.
Stamp 14.12. Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/cf07a47dc0c3b16778291e62d730537b45da51ef Modified Files -- configure| 18 +- configure.ac | 2 +- 2 files changed, 10 insertions(+), 10 deletions(-)
pgsql: Stamp 15.7.
Stamp 15.7. Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4a53584cf2d676e685d899d01cde18c075fbeca7 Modified Files -- configure| 18 +- configure.ac | 2 +- 2 files changed, 10 insertions(+), 10 deletions(-)
pgsql: Stamp 16.3.
Stamp 16.3. Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/05ffe9398b758bbb8d30cc76e9bbc638dab2d477 Modified Files -- configure| 18 +- configure.ac | 2 +- meson.build | 2 +- 3 files changed, 11 insertions(+), 11 deletions(-)
pgsql: Finish incomplete revert of ec63622c0.
Finish incomplete revert of ec63622c0. The code change this made might well be fine to keep, but the comment justifying it by reference to self-join removal isn't. Let's just go back to the status quo ante, pending a more thorough review/redesign of SJE. (I found this by grepping to see if any references to self-join removal remained in the tree.) Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/07746a8ef2a871d904c26364cdca4e7feeffe395 Modified Files -- src/backend/optimizer/prep/prepunion.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-)
pgsql: Release notes for 16.3, 15.7, 14.12, 13.15, 12.19.
Release notes for 16.3, 15.7, 14.12, 13.15, 12.19. Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9fc09cc294ff9fcf961758bf4d020c9899c4af13 Modified Files -- doc/src/sgml/release-16.sgml | 18 -- 1 file changed, 18 deletions(-)
pgsql: Release notes for 16.3, 15.7, 14.12, 13.15, 12.19.
Release notes for 16.3, 15.7, 14.12, 13.15, 12.19. Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1272af45d6230803eb1cf03a84b98fd6c4173a9f Modified Files -- doc/src/sgml/release-12.sgml | 806 +++ 1 file changed, 806 insertions(+)
pgsql: Release notes for 16.3, 15.7, 14.12, 13.15, 12.19.
Release notes for 16.3, 15.7, 14.12, 13.15, 12.19. Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ac7049dbf33943d5ecbadfdb0f2091fa4ff88748 Modified Files -- doc/src/sgml/release-15.sgml | 1108 ++ 1 file changed, 1108 insertions(+)
pgsql: Release notes for 16.3, 15.7, 14.12, 13.15, 12.19.
Release notes for 16.3, 15.7, 14.12, 13.15, 12.19. Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/6cb4d1d486220c8e194009466ea5a25108afb19c Modified Files -- doc/src/sgml/release-14.sgml | 915 +++ 1 file changed, 915 insertions(+)
pgsql: Release notes for 16.3, 15.7, 14.12, 13.15, 12.19.
Release notes for 16.3, 15.7, 14.12, 13.15, 12.19. Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2bfd5ea56edca1521404e180730d56fa4c379f27 Modified Files -- doc/src/sgml/release-13.sgml | 800 +++ 1 file changed, 800 insertions(+)
pgsql: Silence Coverity complaint about possible null-pointer dereferen
Silence Coverity complaint about possible null-pointer dereference. If pg_init_privs were to contain a NULL ACL field, this code would pass old_acl == NULL to merge_acl_with_grant, which would crash. The case shouldn't happen, but it just takes a couple more lines of code to guard against it, so do so. Oversight in 534287403; no back-patch needed. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/713cfaf2a576a9896fdd9b5aad51f6ebeb91a3c7 Modified Files -- src/backend/catalog/aclchk.c | 19 +++ 1 file changed, 11 insertions(+), 8 deletions(-)
pgsql: First-draft release notes for 16.3.
First-draft release notes for 16.3. As usual, the release notes for other branches will be made by cutting these down, but put them up for community review first. Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7155cc4a60e7bfc837233b2dea2563a2edc673fd Modified Files -- doc/src/sgml/release-16.sgml | 1211 ++ 1 file changed, 1211 insertions(+)
pgsql: Allow selecting the git revision to be packaged by "make dist".
Allow selecting the git revision to be packaged by "make dist". Commit 619bc23a1 changed "make dist" to invoke "git archive", but hard-wired the call to specify that the HEAD revision should be packaged. Our tarball building process needs to be able to specify which git commit to package (notably, for packaging back branches). While we could make that work with some hackery to operate in detached-HEAD state, it's a lot nicer just to expose git archive's ability to specify what to package. Hence, invent a new make variable PG_GIT_REVISION. This is undocumented, but so is "make dist". Also make corresponding changes in the meson scripts. We have no near-term intention of using that for package building, but it will likely happen eventually, so stay prepared. Discussion: https://postgr.es/m/3552543.1713909...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/01df14763431df1506cbae206945cd165c66d1d3 Modified Files -- GNUmakefile.in| 7 +-- meson.build | 6 -- meson_options.txt | 3 +++ 3 files changed, 12 insertions(+), 4 deletions(-)
pgsql: Throw a more on-point error for publications depending on column
Throw a more on-point error for publications depending on columns. Same as 42b041243, except that the trouble case is a publication WHERE clause that depends on a column. Again reported by Alexander Lakhin. Back-patch to v15 where we added publication WHERE clauses. Discussion: https://postgr.es/m/548a47bc-87ae-b3df-c6a2-60b9966f8...@gmail.com Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5f4a1a0a7758bb3bd0cfa58a48a1537bb2c0024b Modified Files -- src/backend/commands/tablecmds.c | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-)
pgsql: Throw a more on-point error for publications depending on column
Throw a more on-point error for publications depending on columns. Same as 42b041243, except that the trouble case is a publication WHERE clause that depends on a column. Again reported by Alexander Lakhin. Back-patch to v15 where we added publication WHERE clauses. Discussion: https://postgr.es/m/548a47bc-87ae-b3df-c6a2-60b9966f8...@gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/91e7115b177b0523f9757574b8a329ebe10c0af7 Modified Files -- src/backend/commands/tablecmds.c | 16 1 file changed, 16 insertions(+)
pgsql: Throw a more on-point error for publications depending on column
Throw a more on-point error for publications depending on columns. Same as 42b041243, except that the trouble case is a publication WHERE clause that depends on a column. Again reported by Alexander Lakhin. Back-patch to v15 where we added publication WHERE clauses. Discussion: https://postgr.es/m/548a47bc-87ae-b3df-c6a2-60b9966f8...@gmail.com Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/11d40a44ba325f254562a3fbd8ccd2791f12b9b5 Modified Files -- src/backend/commands/tablecmds.c | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-)
Re: pgsql: Disable run condition optimization for some WindowFuncs
David Rowley writes:
> On Wed, 1 May 2024 at 17:02, Tatsuo Ishii wrote:
>> Maybe you are talking about BUG #18305:
> Thanks for pointing it out. There's not much I can do to correct the
> commit message now.
Yeah, once pushed commit messages are pretty much graven on stone
tablets. But we do have a history of posting corrections in this
mailing list, just in case future hackers want to track something
down.
regards, tom lane
pgsql: Disallow converting a table to a view within an outer SQL comman
Disallow converting a table to a view within an outer SQL command. We have long disallowed all forms of ALTER TABLE if the table is already opened by some outer SQL command in the same session. This has the same purpose as obtaining AccessExclusiveLock, but since a session's own locks don't conflict the lock only blocks use of the table by other sessions, not our own. Without this check, the ALTER might confuse the outer SQL command since any previous inspection of the table would potentially become invalid. However, the RelisBecomingView code path in DefineQueryRewrite never got that memo, and assumed that AccessExclusiveLock is sufficient for performing something morally equivalent to a rather invasive ALTER TABLE. Unsurprisingly, this can confuse an outer command that is trying to do something with the table. This was submitted as a security issue, but the security team has been unable to identify any consequence worse than a null pointer dereference (from trying to access rd_tableam methods that the relation no longer has). Therefore, in accordance with our usual policy, it's not security material and should just be fixed as a routine bug. Fix by disallowing the operation if the table is open locally, exactly as ALTER TABLE does it. Per an anonymous security researcher, via Bundesamt für Sicherheit in der Informationstechnik. Patch v12-v15 only. In v16 and later, we removed this code altogether (cf. commit b23cd185f), so that there's no issue. Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1ee22d1e87b3c442928abe9535d6b2bf8460fc67 Modified Files -- src/backend/rewrite/rewriteDefine.c | 6 ++ 1 file changed, 6 insertions(+)
pgsql: Disallow converting a table to a view within an outer SQL comman
Disallow converting a table to a view within an outer SQL command. We have long disallowed all forms of ALTER TABLE if the table is already opened by some outer SQL command in the same session. This has the same purpose as obtaining AccessExclusiveLock, but since a session's own locks don't conflict the lock only blocks use of the table by other sessions, not our own. Without this check, the ALTER might confuse the outer SQL command since any previous inspection of the table would potentially become invalid. However, the RelisBecomingView code path in DefineQueryRewrite never got that memo, and assumed that AccessExclusiveLock is sufficient for performing something morally equivalent to a rather invasive ALTER TABLE. Unsurprisingly, this can confuse an outer command that is trying to do something with the table. This was submitted as a security issue, but the security team has been unable to identify any consequence worse than a null pointer dereference (from trying to access rd_tableam methods that the relation no longer has). Therefore, in accordance with our usual policy, it's not security material and should just be fixed as a routine bug. Fix by disallowing the operation if the table is open locally, exactly as ALTER TABLE does it. Per an anonymous security researcher, via Bundesamt für Sicherheit in der Informationstechnik. Patch v12-v15 only. In v16 and later, we removed this code altogether (cf. commit b23cd185f), so that there's no issue. Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/bf379b555c06034bcd1be384cc145d8264213f41 Modified Files -- src/backend/rewrite/rewriteDefine.c | 6 ++ 1 file changed, 6 insertions(+)
pgsql: Disallow converting a table to a view within an outer SQL comman
Disallow converting a table to a view within an outer SQL command. We have long disallowed all forms of ALTER TABLE if the table is already opened by some outer SQL command in the same session. This has the same purpose as obtaining AccessExclusiveLock, but since a session's own locks don't conflict the lock only blocks use of the table by other sessions, not our own. Without this check, the ALTER might confuse the outer SQL command since any previous inspection of the table would potentially become invalid. However, the RelisBecomingView code path in DefineQueryRewrite never got that memo, and assumed that AccessExclusiveLock is sufficient for performing something morally equivalent to a rather invasive ALTER TABLE. Unsurprisingly, this can confuse an outer command that is trying to do something with the table. This was submitted as a security issue, but the security team has been unable to identify any consequence worse than a null pointer dereference (from trying to access rd_tableam methods that the relation no longer has). Therefore, in accordance with our usual policy, it's not security material and should just be fixed as a routine bug. Fix by disallowing the operation if the table is open locally, exactly as ALTER TABLE does it. Per an anonymous security researcher, via Bundesamt für Sicherheit in der Informationstechnik. Patch v12-v15 only. In v16 and later, we removed this code altogether (cf. commit b23cd185f), so that there's no issue. Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/56d30fb10d5ce5e2d8b432eeaca8ecf2fc2a6900 Modified Files -- src/backend/rewrite/rewriteDefine.c | 6 ++ 1 file changed, 6 insertions(+)
pgsql: Disallow converting a table to a view within an outer SQL comman
Disallow converting a table to a view within an outer SQL command. We have long disallowed all forms of ALTER TABLE if the table is already opened by some outer SQL command in the same session. This has the same purpose as obtaining AccessExclusiveLock, but since a session's own locks don't conflict the lock only blocks use of the table by other sessions, not our own. Without this check, the ALTER might confuse the outer SQL command since any previous inspection of the table would potentially become invalid. However, the RelisBecomingView code path in DefineQueryRewrite never got that memo, and assumed that AccessExclusiveLock is sufficient for performing something morally equivalent to a rather invasive ALTER TABLE. Unsurprisingly, this can confuse an outer command that is trying to do something with the table. This was submitted as a security issue, but the security team has been unable to identify any consequence worse than a null pointer dereference (from trying to access rd_tableam methods that the relation no longer has). Therefore, in accordance with our usual policy, it's not security material and should just be fixed as a routine bug. Fix by disallowing the operation if the table is open locally, exactly as ALTER TABLE does it. Per an anonymous security researcher, via Bundesamt für Sicherheit in der Informationstechnik. Patch v12-v15 only. In v16 and later, we removed this code altogether (cf. commit b23cd185f), so that there's no issue. Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/51189f98a9fc88a63ae6a9635da8adb427f9958c Modified Files -- src/backend/rewrite/rewriteDefine.c | 6 ++ 1 file changed, 6 insertions(+)
pgsql: Fix one more portability shortcoming in new test_pg_dump test.
Fix one more portability shortcoming in new test_pg_dump test. If the bootstrap superuser's name requires quoting, regroleout will supply double quotes ... but the result of CURRENT_USER is just the literal name. Apply quote_ident() to ensure a match. Per Andrew Dunstan's off-list investigation of buildfarm member prion's failures. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d12b4ba1bd3eedd862064cf1dad5ff107c5cba90 Modified Files -- src/test/modules/test_pg_dump/expected/test_pg_dump.out | 8 src/test/modules/test_pg_dump/sql/test_pg_dump.sql | 8 2 files changed, 8 insertions(+), 8 deletions(-)
Re: pgsql: Reject SSL connection if ALPN is used but there's no common prot
Heikki Linnakangas writes:
> On 30/04/2024 02:32, Tom Lane wrote:
>> A moderately large fraction of the buildfarm doesn't seem to
>> recognize SSL_AD_NO_APPLICATION_PROTOCOL.
> *sigh*. I checked that it exists on OpenSSL 1.1.1, but according to
> buildfarm it's not present on OpenSSL 1.0.2 or LibreSSL. I'll add an
> #ifdef guard. OpenSSL 1.0.2 support is about to be removed from master,
> and, and we can live with a a poor error message on LibreSSL. It's not
> something that users should normally hit.
WFM. Thanks!
regards, tom lane
Re: pgsql: Fix test case from b0c5b215d.
David Rowley writes:
> On Tue, 30 Apr 2024 at 14:14, Tom Lane wrote:
>> Yeah, the affected buildfarm members seem still not happy.
> Isn't your latest fix adding COLLATE "C" to the wrong test?
Oh! No, it was definitely adjusting a test that needed it,
just not the only one :-(. Thanks for the fresh eyes.
regards, tom lane
pgsql: Force COLLATE "C" to stabilize ordering, redux.
Force COLLATE "C" to stabilize ordering, redux. David Rowley correctly pointed out that I'd collat-ified only one of the two troublesome queries. Definitely not my day. Discussion: https://postgr.es/m/caaphdvo8pmk5wwfaqwgzuq-xh+957w61io_oscp0ouzqcco...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b7dc5da1969cb0756739feb393eea51a8265ca04 Modified Files -- src/test/modules/test_pg_dump/expected/test_pg_dump.out | 4 ++-- src/test/modules/test_pg_dump/sql/test_pg_dump.sql | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)
Re: pgsql: Fix test case from b0c5b215d.
I wrote: > I committed that suggestion, but I'm not sure it's enough to fix it, > because if I do > LANG=cs_CZ.utf8 make check > then I still get variant output order. I tried about six different > spellings of the query without improving matters, so I'm totally > baffled. Have we managed to break COLLATE "C"? (With one eye on > Jeff Davis' recent stuff, I could believe that, except I'd have > expected it to show up in other regression tests already.) Yeah, the affected buildfarm members seem still not happy. In simple testing such as select * from foo order by f1 collate "C"; the behavior seems as expected. I also confirmed that I see the test misbehavior locally with or without ICU. So I kind of think that this is not a failure in the sorting code per se. My current idea is that in a more complicated query such as the new test_pg_dump query, we are somehow losing the COLLATE "C" specification --- it's there in the Sort node according to EXPLAIN VERBOSE, but it sure doesn't seem to be having any effect. I'm too tired to look any closer tonight, though. regards, tom lane
Re: pgsql: Fix test case from b0c5b215d.
David Rowley writes:
> Still failing for me and [1].
> Maybe:
> SELECT pg_describe_object(classid,objid,objsubid) COLLATE "C" AS obj,
> Gets me the results in the expected order.
I committed that suggestion, but I'm not sure it's enough to fix it,
because if I do
LANG=cs_CZ.utf8 make check
then I still get variant output order. I tried about six different
spellings of the query without improving matters, so I'm totally
baffled. Have we managed to break COLLATE "C"? (With one eye on
Jeff Davis' recent stuff, I could believe that, except I'd have
expected it to show up in other regression tests already.)
I'll await buildfarm results, but there's something odd here.
regards, tom lane
pgsql: Force COLLATE "C" to stabilize ordering in new test_pg_dump quer
Force COLLATE "C" to stabilize ordering in new test_pg_dump queries. Should have thought of the need for this. (Local testing suggests that we may still not be out of the woods, but certainly this much is needed.) Per buildfarm and David Rowley. Discussion: https://postgr.es/m/caaphdvo8pmk5wwfaqwgzuq-xh+957w61io_oscp0ouzqcco...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/900d1144256a63250a2e326567b636ee3220b731 Modified Files -- src/test/modules/test_pg_dump/expected/test_pg_dump.out | 4 ++-- src/test/modules/test_pg_dump/sql/test_pg_dump.sql | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)
Re: pgsql: Fix test case from b0c5b215d.
David Rowley writes:
> Maybe:
> SELECT pg_describe_object(classid,objid,objsubid) COLLATE "C" AS obj,
Argh, I knew better than to not specify COLLATE "C".
This commit's feeling a little snakebit.
regards, tom lane
pgsql: Fix test case from b0c5b215d.
Fix test case from b0c5b215d. I'd not checked that this iteration of the test actually worked with a bootstrap superuser not named 'postgres'. It didn't, because the coercion rules for CASE caused us to try to cast the 'postgres' literal to regrole. Mea culpa. Per buildfarm (via Alexander Korotkov) Discussion: https://postgr.es/m/CAPpHfdsV=itvh6b858hnh1blgewyh6cdtno_eoow9eoa8ke...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/9d9ece4c16dbbaf3b9d60c2fe201b8e99a407be3 Modified Files -- src/test/modules/test_pg_dump/expected/test_pg_dump.out | 8 src/test/modules/test_pg_dump/sql/test_pg_dump.sql | 8 2 files changed, 8 insertions(+), 8 deletions(-)
Re: pgsql: Fix failure to track role dependencies of pg_init_privs entries.
Alexander Korotkov writes: > I just noticed that test_pg_dump checks don't pass for me. And for > most of the buildfarm members too. > You must be already aware of this, just in case. D'oh. Should have actually checked that test with a non-'postgres' superuser. Will fix in a few. regards, tom lane
pgsql: Allow meson builds to run test_pg_dump test in installcheck mode
Allow meson builds to run test_pg_dump test in installcheck mode. This had been disabled because the test "doesn't delete its user". It doesn't seem like a great idea for the meson tests to act differently from the makefile tests, though, and the makefiles had no such exception (which is how come only copperhead noticed the problem just fixed in 534287403). In any case, the premise is false since 936e3fa37, so let's remove the restriction. Discussion: https://postgr.es/m/2857513.1713733...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b0c5b215dace219ecf3b42cc2eb90abf7fd7a582 Modified Files -- src/test/modules/test_pg_dump/meson.build | 2 -- 1 file changed, 2 deletions(-)
Re: pgsql: Reject SSL connection if ALPN is used but there's no common prot
Heikki Linnakangas writes: > Reject SSL connection if ALPN is used but there's no common protocol A moderately large fraction of the buildfarm doesn't seem to recognize SSL_AD_NO_APPLICATION_PROTOCOL. regards, tom lane
pgsql: Fix failure to track role dependencies of pg_init_privs entries.
Fix failure to track role dependencies of pg_init_privs entries. If an ACL recorded in pg_init_privs mentions a non-pinned role, that reference must also be noted in pg_shdepend so that we know that the role can't go away without removing the ACL reference. Otherwise, DROP ROLE could succeed and leave dangling entries behind, which is what's causing the recent upgrade-check failures on buildfarm member copperhead. This has been wrong since pg_init_privs was introduced, but it's escaped notice because typical pg_init_privs entries would only mention the bootstrap superuser (pinned) or at worst the owner of the extension (who can't go away before the extension does). We lack even a representation of such a role reference for pg_shdepend. My first thought for a solution was entries listing pg_init_privs in classid, but that doesn't work because then there's noplace to put the granted-on object's classid. Rather than adding a new column to pg_shdepend, let's add a new deptype code SHARED_DEPENDENCY_INITACL. Much of the associated boilerplate code can be cribbed from code for SHARED_DEPENDENCY_ACL. A lot of the bulk of this patch just stems from the new need to pass the object's owner ID to recordExtensionInitPriv, so that we can consult it while updating pg_shdepend. While many callers have that at hand already, a few places now need to fetch the owner ID of an arbitrary privilege-bearing object. For that, we assume that there is a catcache on the relevant catalog's OID column, which is an assumption already made in ExecGrant_common so it seems okay here. We do need an entirely new routine RemoveRoleFromInitPriv to perform cleanup of pg_init_privs ACLs during DROP OWNED BY. It's analogous to RemoveRoleFromObjectACL, but we can't share logic because that function operates by building a command parsetree and invoking existing GRANT/REVOKE infrastructure. There is of course no SQL command that would update pg_init_privs entries when we're not in process of creating their extension, so we need a routine that can do the updates directly. catversion bump because this changes the expected contents of pg_shdepend. For the same reason, there's no hope of back-patching this, even though it fixes a longstanding bug. Fortunately, the case where it's a problem seems to be near nonexistent in the field. If it weren't for the buildfarm breakage, I'd have been content to leave this for v18. Patch by me; thanks to Daniel Gustafsson for review and discussion. Discussion: https://postgr.es/m/1745535.1712358...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/534287403914cc9760db98f7320ac4e92f5d416e Modified Files -- doc/src/sgml/catalogs.sgml | 14 ++ src/backend/catalog/aclchk.c | 262 +++-- src/backend/catalog/pg_shdepend.c | 56 - src/include/catalog/catversion.h | 2 +- src/include/catalog/dependency.h | 16 +- src/include/utils/acl.h| 2 + .../modules/test_pg_dump/expected/test_pg_dump.out | 183 ++ src/test/modules/test_pg_dump/sql/test_pg_dump.sql | 37 +++ 8 files changed, 549 insertions(+), 23 deletions(-)
pgsql: Throw a more on-point error for functions depending on columns.
Throw a more on-point error for functions depending on columns. ALTER COLUMN TYPE wasn't expecting to find any pg_proc objects depending on the column whose type is to be altered. That indeed wasn't possible when this code was written, but it is possible since we introduced new-style SQL function bodies. It's about as difficult to fix this case as it is to fix dependent views, and we've been punting on those for years, so I don't feel too awful about punting for functions too. (I sure wouldn't risk back-patching such code.) So just throw a more user-facing error. Also, adjust some of the existing comments to reflect that these are all pretty much the same issue. (This patch also fixes it so we will tolerate finding such a dependency during ALTER COLUMN SET EXPRESSION; in that, we need not do anything to the function, so no error is wanted. That problem is new in HEAD.) Per bug #18449 from Alexander Lakhin. Back-patch to v14 where we added new-style SQL functions. Discussion: https://postgr.es/m/18449-f8248467aaa29...@postgresql.org Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/617a23927249c78f23ef005aaa78b508570f4cc8 Modified Files -- src/backend/commands/tablecmds.c | 30 +- 1 file changed, 25 insertions(+), 5 deletions(-)
pgsql: Throw a more on-point error for functions depending on columns.
Throw a more on-point error for functions depending on columns. ALTER COLUMN TYPE wasn't expecting to find any pg_proc objects depending on the column whose type is to be altered. That indeed wasn't possible when this code was written, but it is possible since we introduced new-style SQL function bodies. It's about as difficult to fix this case as it is to fix dependent views, and we've been punting on those for years, so I don't feel too awful about punting for functions too. (I sure wouldn't risk back-patching such code.) So just throw a more user-facing error. Also, adjust some of the existing comments to reflect that these are all pretty much the same issue. (This patch also fixes it so we will tolerate finding such a dependency during ALTER COLUMN SET EXPRESSION; in that, we need not do anything to the function, so no error is wanted. That problem is new in HEAD.) Per bug #18449 from Alexander Lakhin. Back-patch to v14 where we added new-style SQL functions. Discussion: https://postgr.es/m/18449-f8248467aaa29...@postgresql.org Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/9b41d1d634aa9a3a36a21c5624b25c8475fd51ee Modified Files -- src/backend/commands/tablecmds.c | 30 +- 1 file changed, 25 insertions(+), 5 deletions(-)
pgsql: Throw a more on-point error for functions depending on columns.
Throw a more on-point error for functions depending on columns. ALTER COLUMN TYPE wasn't expecting to find any pg_proc objects depending on the column whose type is to be altered. That indeed wasn't possible when this code was written, but it is possible since we introduced new-style SQL function bodies. It's about as difficult to fix this case as it is to fix dependent views, and we've been punting on those for years, so I don't feel too awful about punting for functions too. (I sure wouldn't risk back-patching such code.) So just throw a more user-facing error. Also, adjust some of the existing comments to reflect that these are all pretty much the same issue. (This patch also fixes it so we will tolerate finding such a dependency during ALTER COLUMN SET EXPRESSION; in that, we need not do anything to the function, so no error is wanted. That problem is new in HEAD.) Per bug #18449 from Alexander Lakhin. Back-patch to v14 where we added new-style SQL functions. Discussion: https://postgr.es/m/18449-f8248467aaa29...@postgresql.org Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b19255ca66f74fe9f8d0372db7d644d0bb4d6ac9 Modified Files -- src/backend/commands/tablecmds.c | 30 +- 1 file changed, 25 insertions(+), 5 deletions(-)
pgsql: Throw a more on-point error for functions depending on columns.
Throw a more on-point error for functions depending on columns. ALTER COLUMN TYPE wasn't expecting to find any pg_proc objects depending on the column whose type is to be altered. That indeed wasn't possible when this code was written, but it is possible since we introduced new-style SQL function bodies. It's about as difficult to fix this case as it is to fix dependent views, and we've been punting on those for years, so I don't feel too awful about punting for functions too. (I sure wouldn't risk back-patching such code.) So just throw a more user-facing error. Also, adjust some of the existing comments to reflect that these are all pretty much the same issue. (This patch also fixes it so we will tolerate finding such a dependency during ALTER COLUMN SET EXPRESSION; in that, we need not do anything to the function, so no error is wanted. That problem is new in HEAD.) Per bug #18449 from Alexander Lakhin. Back-patch to v14 where we added new-style SQL functions. Discussion: https://postgr.es/m/18449-f8248467aaa29...@postgresql.org Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/42b041243c00fb20023c983357e7f1ffd3710fff Modified Files -- src/backend/commands/tablecmds.c | 34 ++ 1 file changed, 30 insertions(+), 4 deletions(-)
pgsql: Detect more overflows in timestamp[tz]_pl_interval.
Detect more overflows in timestamp[tz]_pl_interval. In commit 25cd2d640 I (tgl) opined that "The additions of the months and microseconds fields could also overflow, of course. However, I believe we need no additional checks there; the existing range checks should catch such cases". This is demonstrably wrong however for the microseconds field, and given that discovery it seems prudent to be paranoid about the months addition as well. Report and patch by Joseph Koshakow. As before, back-patch to all supported branches. (However, the test case doesn't work before v15 because we didn't allow wider-than-int32 numbers in interval literals. A variant test could probably be built that fits within that restriction, but it didn't seem worth the trouble.) Discussion: https://postgr.es/m/caavxfhf77srhkoezuw9_cmyspbpns2c+j_+8dq4+0oi8iko...@mail.gmail.com Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/1748379b636152b6633498c6488fd98aa015bc99 Modified Files -- src/backend/utils/adt/timestamp.c | 20 1 file changed, 16 insertions(+), 4 deletions(-)
