pgsql: Improve test coverage in bump.c
Improve test coverage in bump.c There were no callers of BumpAllocLarge() in the regression tests, so here we add a sort with a tuple large enough to use that path in bump.c. Also, BumpStats() wasn't being called, so add a test to sysviews.sql to call pg_backend_memory_contexts() while a bump context exists in the backend. Reported-by: Andres Freund Discussion: https://postgr.es/m/20240414223305.m3i5eju6zylab...@awork3.anarazel.de Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/bea97cd02ebb347ab469b78673c2b33a72109669 Modified Files -- src/test/regress/expected/sysviews.out | 23 +++ src/test/regress/expected/tuplesort.out | 13 + src/test/regress/sql/sysviews.sql | 15 +++ src/test/regress/sql/tuplesort.sql | 9 + 4 files changed, 60 insertions(+)
pgsql: xml2: Replace deprecated routines with recommended ones
xml2: Replace deprecated routines with recommended ones Some functions are used in the tree and are currently marked as deprecated by upstream. This commit refreshes the code to use the recommended functions, leading to the following changes: - xmlSubstituteEntitiesDefault() is gone, and needs to be replaced with XML_PARSE_NOENT for the paths doing the parsing. - xmlParseMemory() -> xmlReadMemory(). These functions, as well as more functions setting global states, have been officially marked as deprecated by upstream in August 2022. Their replacements exist since the 2001-ish area, as far as I have checked, so that should be safe. This has been originally applied as 65c5864d7fac without a backpatch, and this has come up as well when working on 400928b83. Per request from Tom Lane, for new buildfarm member indri that is able to see deprecation warnings with xmlSubstituteEntitiesDefault() in 16 and older stable branches. Author: Dmitry Koval Discussion: https://postgr.es/m/18274-98d16bc035206...@postgresql.org Discussion: https://postgr.es/m/1012981.1713222...@sss.pgh.pa.us Bakpatch-through: 12 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7c93f31dee5ff740b1367db472e69cdd290d8de2 Modified Files -- contrib/xml2/xpath.c | 11 ++- contrib/xml2/xslt_proc.c | 10 ++ 2 files changed, 12 insertions(+), 9 deletions(-)
pgsql: xml2: Replace deprecated routines with recommended ones
xml2: Replace deprecated routines with recommended ones Some functions are used in the tree and are currently marked as deprecated by upstream. This commit refreshes the code to use the recommended functions, leading to the following changes: - xmlSubstituteEntitiesDefault() is gone, and needs to be replaced with XML_PARSE_NOENT for the paths doing the parsing. - xmlParseMemory() -> xmlReadMemory(). These functions, as well as more functions setting global states, have been officially marked as deprecated by upstream in August 2022. Their replacements exist since the 2001-ish area, as far as I have checked, so that should be safe. This has been originally applied as 65c5864d7fac without a backpatch, and this has come up as well when working on 400928b83. Per request from Tom Lane, for new buildfarm member indri that is able to see deprecation warnings with xmlSubstituteEntitiesDefault() in 16 and older stable branches. Author: Dmitry Koval Discussion: https://postgr.es/m/18274-98d16bc035206...@postgresql.org Discussion: https://postgr.es/m/1012981.1713222...@sss.pgh.pa.us Bakpatch-through: 12 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/689ba4f1c4067005af0a71ba0cc52365474c4e4a Modified Files -- contrib/xml2/xpath.c | 11 ++- contrib/xml2/xslt_proc.c | 10 ++ 2 files changed, 12 insertions(+), 9 deletions(-)
pgsql: xml2: Replace deprecated routines with recommended ones
xml2: Replace deprecated routines with recommended ones Some functions are used in the tree and are currently marked as deprecated by upstream. This commit refreshes the code to use the recommended functions, leading to the following changes: - xmlSubstituteEntitiesDefault() is gone, and needs to be replaced with XML_PARSE_NOENT for the paths doing the parsing. - xmlParseMemory() -> xmlReadMemory(). These functions, as well as more functions setting global states, have been officially marked as deprecated by upstream in August 2022. Their replacements exist since the 2001-ish area, as far as I have checked, so that should be safe. This has been originally applied as 65c5864d7fac without a backpatch, and this has come up as well when working on 400928b83. Per request from Tom Lane, for new buildfarm member indri that is able to see deprecation warnings with xmlSubstituteEntitiesDefault() in 16 and older stable branches. Author: Dmitry Koval Discussion: https://postgr.es/m/18274-98d16bc035206...@postgresql.org Discussion: https://postgr.es/m/1012981.1713222...@sss.pgh.pa.us Bakpatch-through: 12 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/6fa5e67e832bbab80ea7b936701e2c03c22fe059 Modified Files -- contrib/xml2/xpath.c | 14 -- contrib/xml2/xslt_proc.c | 10 ++ 2 files changed, 14 insertions(+), 10 deletions(-)
pgsql: xml2: Replace deprecated routines with recommended ones
xml2: Replace deprecated routines with recommended ones Some functions are used in the tree and are currently marked as deprecated by upstream. This commit refreshes the code to use the recommended functions, leading to the following changes: - xmlSubstituteEntitiesDefault() is gone, and needs to be replaced with XML_PARSE_NOENT for the paths doing the parsing. - xmlParseMemory() -> xmlReadMemory(). These functions, as well as more functions setting global states, have been officially marked as deprecated by upstream in August 2022. Their replacements exist since the 2001-ish area, as far as I have checked, so that should be safe. This has been originally applied as 65c5864d7fac without a backpatch, and this has come up as well when working on 400928b83. Per request from Tom Lane, for new buildfarm member indri that is able to see deprecation warnings with xmlSubstituteEntitiesDefault() in 16 and older stable branches. Author: Dmitry Koval Discussion: https://postgr.es/m/18274-98d16bc035206...@postgresql.org Discussion: https://postgr.es/m/1012981.1713222...@sss.pgh.pa.us Bakpatch-through: 12 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/bb418aeee27078e2f3955a131515c151173143bd Modified Files -- contrib/xml2/xpath.c | 14 -- contrib/xml2/xslt_proc.c | 10 ++ 2 files changed, 14 insertions(+), 10 deletions(-)
pgsql: xml2: Replace deprecated routines with recommended ones
xml2: Replace deprecated routines with recommended ones Some functions are used in the tree and are currently marked as deprecated by upstream. This commit refreshes the code to use the recommended functions, leading to the following changes: - xmlSubstituteEntitiesDefault() is gone, and needs to be replaced with XML_PARSE_NOENT for the paths doing the parsing. - xmlParseMemory() -> xmlReadMemory(). These functions, as well as more functions setting global states, have been officially marked as deprecated by upstream in August 2022. Their replacements exist since the 2001-ish area, as far as I have checked, so that should be safe. This has been originally applied as 65c5864d7fac without a backpatch, and this has come up as well when working on 400928b83. Per request from Tom Lane, for new buildfarm member indri that is able to see deprecation warnings with xmlSubstituteEntitiesDefault() in 16 and older stable branches. Author: Dmitry Koval Discussion: https://postgr.es/m/18274-98d16bc035206...@postgresql.org Discussion: https://postgr.es/m/1012981.1713222...@sss.pgh.pa.us Bakpatch-through: 12 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4b0e5d6012918de2069a2636aacf60bbc6c0085c Modified Files -- contrib/xml2/xpath.c | 14 -- contrib/xml2/xslt_proc.c | 10 ++ 2 files changed, 14 insertions(+), 10 deletions(-)
Re: pgsql: Move code for backend startup to separate file
On Mon, Apr 15, 2024 at 05:24:39PM +0900, Michael Paquier wrote: > extern PGDLLIMPORT const char *progname; > > +extern bool LoadedSSL; > > This variable is missing a PGDLLIMPORT, it seems. > > aafc05de1bf5 has missed a second one with MyClientSocket. Both are > declared in postmaster.h. For now, I've fixed these two with 768ceeeaa127. -- Michael signature.asc Description: PGP signature
pgsql: Add missing PGDLLIMPORT markings
Add missing PGDLLIMPORT markings All backend-side variables should be marked with PGDLLIMPORT, as per policy introduced in 8ec569479f. aafc05de1bf5 has forgotten MyClientSocket, and 05c3980e7f47 LoadedSSL. These can be spotted with a command like this one (be careful of not switching __pg_log_level): src/tools/mark_pgdllimport.pl $(git ls-files src/include/) Reported-by: Peter Eisentraut Discussion: https://postgr.es/m/zhzkrzrkkhbeq...@paquier.xyz Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/768ceeeaa127a8001d60ad6a62846a8be3f35d93 Modified Files -- src/include/postmaster/postmaster.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: docs: Consolidate into new "WAL for Extensions" chapter.
docs: Consolidate into new "WAL for Extensions" chapter. Previously, we had consecutive, very short chapters called "Generic WAL" and "Custom WAL Resource Managers," explaining different approaches to the same problem. Merge them into a single chapter. Explain most of the differences between the approaches in the chapter's introductory text, rather than in the individual sections. Discussion: http://postgr.es/m/46ac50c1-6b2a-404f-a683-b67af6ab5...@eisentraut.org Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/09d9800e52822ed20d69d98aaa39d3fb10769c44 Modified Files -- doc/src/sgml/custom-rmgr.sgml| 11 --- doc/src/sgml/filelist.sgml | 1 + doc/src/sgml/generic-wal.sgml| 14 +++--- doc/src/sgml/postgres.sgml | 3 +-- doc/src/sgml/wal-for-extensions.sgml | 32 5 files changed, 41 insertions(+), 20 deletions(-)
pgsql: doc: Note exceptions for SET ROLE's effect on privilege checks.
doc: Note exceptions for SET ROLE's effect on privilege checks. The documentation for SET ROLE states that superusers who switch to a non-superuser role lose their superuser privileges. While this is true for most commands, there are exceptions such as SET ROLE and SET SESSION AUTHORIZATION, which continue to use the current session user and the authenticated user, respectively. Furthermore, the description of this command already describes its effect, so it is arguably unnecessary to include this special case. This commit removes the note about the superuser case and adds a sentence about the aforementioned exceptions to the description. Co-authored-by: Yurii Rashkovskii Reviewed-by: Shubham Khanna, Robert Haas, Michael Paquier Discussion: https://postgr.es/m/CA%2BRLCQysHtME0znk2KUMJN343ksboSRQSU-hCnOjesX6VK300Q%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/953cf49e166a1a64e1eaf2b091b84e02848b8c75 Modified Files -- doc/src/sgml/ref/set_role.sgml | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-)
pgsql: Fix type-checking of RECORD-returning functions in FROM, redux.
Fix type-checking of RECORD-returning functions in FROM, redux. Commit 2ed8f9a01 intended to institute a policy that if a RangeTblFunction has a coldeflist, then the function return type is certainly RECORD, and we should use the coldeflist as the source of truth about what the columns of the record type are. When the original function has been folded to a constant, inspection of the constant might give a different answer. This situation will lead to a tuple-type-mismatch error at execution, but up until that point we need to consistently believe the coldeflist, or we'll have problems from different bits of code reaching different conclusions. expandRTE didn't get that memo though, and would try to produce a tupdesc based on the constant in this situation, leading to an assertion failure. (Desultory testing suggests that non-assert builds often manage to give the expected error, although I also saw a "cache lookup failed for type 0" error, and it seems at least possible that a crash could happen.) Some other callers of get_expr_result_type and get_expr_result_tupdesc were also being incautious about this. While none of them seem to have actual bugs, they're working harder than necessary in this case, besides which it seems safest to have an explicit policy of not using those functions on an RTE with a coldeflist. Adjust the code accordingly, and add commentary to funcapi.c about this policy. Also fix an obsolete comment that claimed "get_expr_result_type() doesn't know how to extract type info from a RECORD constant". That hasn't been true since commit d57534740. Per bug #18422 from Alexander Lakhin. As with the previous commit, back-patch to all supported branches. Discussion: https://postgr.es/m/18422-89ca86c8eac52...@postgresql.org Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e0970862e8685e464a05135cfe813b27c686abb6 Modified Files -- src/backend/optimizer/util/clauses.c | 11 +-- src/backend/parser/parse_relation.c | 19 ++- src/backend/utils/fmgr/funcapi.c | 10 +- src/test/regress/expected/rangefuncs.out | 3 +++ src/test/regress/sql/rangefuncs.sql | 1 + 5 files changed, 32 insertions(+), 12 deletions(-)
pgsql: Fix type-checking of RECORD-returning functions in FROM, redux.
Fix type-checking of RECORD-returning functions in FROM, redux. Commit 2ed8f9a01 intended to institute a policy that if a RangeTblFunction has a coldeflist, then the function return type is certainly RECORD, and we should use the coldeflist as the source of truth about what the columns of the record type are. When the original function has been folded to a constant, inspection of the constant might give a different answer. This situation will lead to a tuple-type-mismatch error at execution, but up until that point we need to consistently believe the coldeflist, or we'll have problems from different bits of code reaching different conclusions. expandRTE didn't get that memo though, and would try to produce a tupdesc based on the constant in this situation, leading to an assertion failure. (Desultory testing suggests that non-assert builds often manage to give the expected error, although I also saw a "cache lookup failed for type 0" error, and it seems at least possible that a crash could happen.) Some other callers of get_expr_result_type and get_expr_result_tupdesc were also being incautious about this. While none of them seem to have actual bugs, they're working harder than necessary in this case, besides which it seems safest to have an explicit policy of not using those functions on an RTE with a coldeflist. Adjust the code accordingly, and add commentary to funcapi.c about this policy. Also fix an obsolete comment that claimed "get_expr_result_type() doesn't know how to extract type info from a RECORD constant". That hasn't been true since commit d57534740. Per bug #18422 from Alexander Lakhin. As with the previous commit, back-patch to all supported branches. Discussion: https://postgr.es/m/18422-89ca86c8eac52...@postgresql.org Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/09989ba84734c07d045ec379c9424508a52ac604 Modified Files -- src/backend/catalog/dependency.c | 6 +- src/backend/optimizer/prep/prepjointree.c | 4 src/backend/optimizer/util/clauses.c | 11 +-- src/backend/parser/parse_relation.c | 19 ++- src/backend/utils/fmgr/funcapi.c | 10 +- src/test/regress/expected/rangefuncs.out | 3 +++ src/test/regress/sql/rangefuncs.sql | 1 + 7 files changed, 41 insertions(+), 13 deletions(-)
pgsql: Fix type-checking of RECORD-returning functions in FROM, redux.
Fix type-checking of RECORD-returning functions in FROM, redux. Commit 2ed8f9a01 intended to institute a policy that if a RangeTblFunction has a coldeflist, then the function return type is certainly RECORD, and we should use the coldeflist as the source of truth about what the columns of the record type are. When the original function has been folded to a constant, inspection of the constant might give a different answer. This situation will lead to a tuple-type-mismatch error at execution, but up until that point we need to consistently believe the coldeflist, or we'll have problems from different bits of code reaching different conclusions. expandRTE didn't get that memo though, and would try to produce a tupdesc based on the constant in this situation, leading to an assertion failure. (Desultory testing suggests that non-assert builds often manage to give the expected error, although I also saw a "cache lookup failed for type 0" error, and it seems at least possible that a crash could happen.) Some other callers of get_expr_result_type and get_expr_result_tupdesc were also being incautious about this. While none of them seem to have actual bugs, they're working harder than necessary in this case, besides which it seems safest to have an explicit policy of not using those functions on an RTE with a coldeflist. Adjust the code accordingly, and add commentary to funcapi.c about this policy. Also fix an obsolete comment that claimed "get_expr_result_type() doesn't know how to extract type info from a RECORD constant". That hasn't been true since commit d57534740. Per bug #18422 from Alexander Lakhin. As with the previous commit, back-patch to all supported branches. Discussion: https://postgr.es/m/18422-89ca86c8eac52...@postgresql.org Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/cc1eb6a3cccdf656df29bf5dd585a4a7068fb814 Modified Files -- src/backend/catalog/dependency.c | 6 +- src/backend/optimizer/prep/prepjointree.c | 4 src/backend/optimizer/util/clauses.c | 11 +-- src/backend/parser/parse_relation.c | 19 ++- src/backend/utils/fmgr/funcapi.c | 10 +- src/test/regress/expected/rangefuncs.out | 3 +++ src/test/regress/sql/rangefuncs.sql | 1 + 7 files changed, 41 insertions(+), 13 deletions(-)
pgsql: Fix type-checking of RECORD-returning functions in FROM, redux.
Fix type-checking of RECORD-returning functions in FROM, redux. Commit 2ed8f9a01 intended to institute a policy that if a RangeTblFunction has a coldeflist, then the function return type is certainly RECORD, and we should use the coldeflist as the source of truth about what the columns of the record type are. When the original function has been folded to a constant, inspection of the constant might give a different answer. This situation will lead to a tuple-type-mismatch error at execution, but up until that point we need to consistently believe the coldeflist, or we'll have problems from different bits of code reaching different conclusions. expandRTE didn't get that memo though, and would try to produce a tupdesc based on the constant in this situation, leading to an assertion failure. (Desultory testing suggests that non-assert builds often manage to give the expected error, although I also saw a "cache lookup failed for type 0" error, and it seems at least possible that a crash could happen.) Some other callers of get_expr_result_type and get_expr_result_tupdesc were also being incautious about this. While none of them seem to have actual bugs, they're working harder than necessary in this case, besides which it seems safest to have an explicit policy of not using those functions on an RTE with a coldeflist. Adjust the code accordingly, and add commentary to funcapi.c about this policy. Also fix an obsolete comment that claimed "get_expr_result_type() doesn't know how to extract type info from a RECORD constant". That hasn't been true since commit d57534740. Per bug #18422 from Alexander Lakhin. As with the previous commit, back-patch to all supported branches. Discussion: https://postgr.es/m/18422-89ca86c8eac52...@postgresql.org Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e0df80828abc0c01fcde123389032370b98f2015 Modified Files -- src/backend/catalog/dependency.c | 6 +- src/backend/optimizer/prep/prepjointree.c | 4 src/backend/optimizer/util/clauses.c | 11 +-- src/backend/parser/parse_relation.c | 19 ++- src/backend/utils/fmgr/funcapi.c | 10 +- src/test/regress/expected/rangefuncs.out | 3 +++ src/test/regress/sql/rangefuncs.sql | 1 + 7 files changed, 41 insertions(+), 13 deletions(-)
pgsql: Fix type-checking of RECORD-returning functions in FROM, redux.
Fix type-checking of RECORD-returning functions in FROM, redux. Commit 2ed8f9a01 intended to institute a policy that if a RangeTblFunction has a coldeflist, then the function return type is certainly RECORD, and we should use the coldeflist as the source of truth about what the columns of the record type are. When the original function has been folded to a constant, inspection of the constant might give a different answer. This situation will lead to a tuple-type-mismatch error at execution, but up until that point we need to consistently believe the coldeflist, or we'll have problems from different bits of code reaching different conclusions. expandRTE didn't get that memo though, and would try to produce a tupdesc based on the constant in this situation, leading to an assertion failure. (Desultory testing suggests that non-assert builds often manage to give the expected error, although I also saw a "cache lookup failed for type 0" error, and it seems at least possible that a crash could happen.) Some other callers of get_expr_result_type and get_expr_result_tupdesc were also being incautious about this. While none of them seem to have actual bugs, they're working harder than necessary in this case, besides which it seems safest to have an explicit policy of not using those functions on an RTE with a coldeflist. Adjust the code accordingly, and add commentary to funcapi.c about this policy. Also fix an obsolete comment that claimed "get_expr_result_type() doesn't know how to extract type info from a RECORD constant". That hasn't been true since commit d57534740. Per bug #18422 from Alexander Lakhin. As with the previous commit, back-patch to all supported branches. Discussion: https://postgr.es/m/18422-89ca86c8eac52...@postgresql.org Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/78e81e14db797713b26ee6fccb371128afa66b4e Modified Files -- src/backend/optimizer/prep/prepjointree.c | 4 src/backend/optimizer/util/clauses.c | 11 +-- src/backend/parser/parse_relation.c | 19 ++- src/backend/utils/fmgr/funcapi.c | 10 +- src/test/regress/expected/rangefuncs.out | 3 +++ src/test/regress/sql/rangefuncs.sql | 1 + 6 files changed, 36 insertions(+), 12 deletions(-)
pgsql: Fix type-checking of RECORD-returning functions in FROM, redux.
Fix type-checking of RECORD-returning functions in FROM, redux. Commit 2ed8f9a01 intended to institute a policy that if a RangeTblFunction has a coldeflist, then the function return type is certainly RECORD, and we should use the coldeflist as the source of truth about what the columns of the record type are. When the original function has been folded to a constant, inspection of the constant might give a different answer. This situation will lead to a tuple-type-mismatch error at execution, but up until that point we need to consistently believe the coldeflist, or we'll have problems from different bits of code reaching different conclusions. expandRTE didn't get that memo though, and would try to produce a tupdesc based on the constant in this situation, leading to an assertion failure. (Desultory testing suggests that non-assert builds often manage to give the expected error, although I also saw a "cache lookup failed for type 0" error, and it seems at least possible that a crash could happen.) Some other callers of get_expr_result_type and get_expr_result_tupdesc were also being incautious about this. While none of them seem to have actual bugs, they're working harder than necessary in this case, besides which it seems safest to have an explicit policy of not using those functions on an RTE with a coldeflist. Adjust the code accordingly, and add commentary to funcapi.c about this policy. Also fix an obsolete comment that claimed "get_expr_result_type() doesn't know how to extract type info from a RECORD constant". That hasn't been true since commit d57534740. Per bug #18422 from Alexander Lakhin. As with the previous commit, back-patch to all supported branches. Discussion: https://postgr.es/m/18422-89ca86c8eac52...@postgresql.org Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b6e21cef72f1f93b0ec4d6da4d9c2e8bb3fca98a Modified Files -- src/backend/optimizer/prep/prepjointree.c | 4 src/backend/optimizer/util/clauses.c | 11 +-- src/backend/parser/parse_relation.c | 19 ++- src/backend/utils/fmgr/funcapi.c | 10 +- src/test/regress/expected/rangefuncs.out | 3 +++ src/test/regress/sql/rangefuncs.sql | 1 + 6 files changed, 36 insertions(+), 12 deletions(-)
pgsql: ATTACH PARTITION: Don't match a PK with a UNIQUE constraint
ATTACH PARTITION: Don't match a PK with a UNIQUE constraint When matching constraints in AttachPartitionEnsureIndexes() we weren't testing the constraint type, which could make a UNIQUE key lacking a not-null constraint incorrectly satisfy a primary key requirement. Fix this by testing that the constraint types match. (Other possible mismatches are verified by comparing index properties.) Discussion: https://postgr.es/m/202402051447.wimb4xmtiiyb@alvherre.pgsql Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/cee8db3f680b737b64d747530b48d30828cf4790 Modified Files -- src/backend/commands/tablecmds.c | 5 + src/backend/utils/cache/lsyscache.c | 22 ++ src/include/utils/lsyscache.h | 2 ++ src/test/regress/expected/constraints.out | 16 src/test/regress/sql/constraints.sql | 7 +++ 5 files changed, 52 insertions(+)
pgsql: Grammar fixes for split/merge partitions code
Grammar fixes for split/merge partitions code The fixes relate to comments, error messages, and corresponding expected output of regression tests. Discussion: https://postgr.es/m/CAMbWs49DDsknxyoycBqiE72VxzL_sYHF6zqL8dSeNehKPJhkKg%40mail.gmail.com Discussion: https://postgr.es/m/86bfd241-a58c-479a-9a72-2c67a02becf8%40postgrespro.ru Discussion: https://postgr.es/m/CAHewXNkGMPU50QG7V6Q60JGFORfo8LfYO1_GCkCa0VWbmB-fEw%40mail.gmail.com Author: Richard Guo, Dmitry Koval, Tender Wang Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/9dfcac8e15acc3b4d4d5bc02383a56ccb07229fe Modified Files -- doc/src/sgml/ddl.sgml | 2 +- doc/src/sgml/ref/alter_table.sgml | 6 +-- src/backend/commands/tablecmds.c | 21 +- src/backend/parser/parse_utilcmd.c| 6 +-- src/backend/partitioning/partbounds.c | 35 src/test/isolation/specs/partition-merge.spec | 2 +- src/test/regress/expected/partition_merge.out | 14 +++ src/test/regress/expected/partition_split.out | 58 +-- src/test/regress/sql/partition_merge.sql | 12 +++--- src/test/regress/sql/partition_split.sql | 48 +++--- 10 files changed, 104 insertions(+), 100 deletions(-)
pgsql: Fix propagating attnotnull in multiple inheritance
Fix propagating attnotnull in multiple inheritance In one of the many strange corner cases of multiple inheritance being used, commit b0e96f311985 missed a CommandCounterIncrement() call after updating the attnotnull flag during ALTER TABLE ADD COLUMN, which caused a catalog tuple to be update attempted twice in the same command, giving rise to a "tuple already updated by self" error. Add the missing call to solve that, and a test case that reproduces the scenario. As a (perhaps surprising) secondary effect, this CCI addition triggers another behavior change: when a primary key is added to a parent partitioned table and the column in an existing partition does not have a not-null constraint, we no longer error out. This will probably be a welcome change by some users, and I think it's unlikely that anybody will miss the old behavior. Reported-by: Alexander Lakhin Discussion: http://postgr.es/m/045dec3f-9b3d-aa44-0c99-85f699230...@gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c3709100be73ad5af7ff536476d4d713bca41b1a Modified Files -- src/backend/commands/tablecmds.c | 4 src/test/regress/expected/constraints.out | 10 +- src/test/regress/expected/inherit.out | 8 src/test/regress/sql/constraints.sql | 7 +++ src/test/regress/sql/inherit.sql | 7 +++ 5 files changed, 35 insertions(+), 1 deletion(-)
Re: pgsql: Move code for backend startup to separate file
Hi Heikki, (Peter E. in CC.) On Mon, Mar 18, 2024 at 09:40:36AM +, Heikki Linnakangas wrote: > Move code for backend startup to separate file > > This is code that runs in the backend process after forking, rather > than postmaster. Move it out of postmaster.c for clarity. > > Reviewed-by: Tristan Partin, Andres Freund > Discussion: > https://www.postgresql.org/message-id/7a59b073-5b5b-151e-7ed3-8b01ff7ce...@iki.fi --- a/src/include/postmaster/postmaster.h +++ b/src/include/postmaster/postmaster.h @@ -52,6 +52,8 @@ extern PGDLLIMPORT int postmaster_alive_fds[2]; extern PGDLLIMPORT const char *progname; +extern bool LoadedSSL; This variable is missing a PGDLLIMPORT, it seems. aafc05de1bf5 has missed a second one with MyClientSocket. Both are declared in postmaster.h. The credit goes to Peter Eisentraunt for noticing these two who has mentioned that to me on mastodon, while I am not able to parse correctly a set of diffs. This stuff can be spotted with a command like this one: src/tools/mark_pgdllimport.pl $(git ls-files *.h) Thanks, -- Michael signature.asc Description: PGP signature
pgsql: psql: Make output of \dD more stable
psql: Make output of \dD more stable \dD showed domain check constraints in arbitrary order, which can cause regression test failures, which was exposed by commit 9895b35cb8. To fix, order the constraints by conname, which matches what psql does in other queries listing constraints. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6ff21c05302592874b8149421711e06043b954fe Modified Files -- src/bin/psql/describe.c | 2 +- src/test/regress/expected/domain.out | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
pgsql: Fix ALTER DOMAIN NOT NULL syntax
Fix ALTER DOMAIN NOT NULL syntax
This addresses a few problems with commit e5da0fe3c22 ("Catalog domain
not-null constraints").
In CREATE DOMAIN, a NOT NULL constraint looks like
CREATE DOMAIN d1 AS int [ CONSTRAINT conname ] NOT NULL
(Before e5da0fe3c22, the constraint name was accepted but ignored.)
But in ALTER DOMAIN, a NOT NULL constraint looks like
ALTER DOMAIN d1 ADD [ CONSTRAINT conname ] NOT NULL VALUE
where VALUE is where for a table constraint the column name would be.
(This works as of e5da0fe3c22. Before e5da0fe3c22, this syntax
resulted in an internal error.)
But for domains, this latter syntax is confusing and needlessly
inconsistent between CREATE and ALTER. So this changes it to just
ALTER DOMAIN d1 ADD [ CONSTRAINT conname ] NOT NULL
(None of these syntaxes are per SQL standard; we are just living with
the bits of inconsistency that have built up over time.)
In passing, this also changes the psql \dD output to not show not-null
constraints in the column "Check", since it's already shown in the
column "Nullable". This has also been off since e5da0fe3c22.
Reviewed-by: jian he
Discussion:
https://www.postgresql.org/message-id/flat/9ec24d7b-633d-463a-84c6-7acff769c9e8%40eisentraut.org
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/9895b35cb88edc30b836661dbc26d7665716b5a0
Modified Files
--
doc/src/sgml/ref/create_domain.sgml | 17 --
src/backend/parser/gram.y| 60 ++--
src/backend/utils/adt/ruleutils.c| 2 +-
src/bin/psql/describe.c | 2 +-
src/test/regress/expected/domain.out | 22 ++---
src/test/regress/sql/domain.sql | 12 +---
6 files changed, 99 insertions(+), 16 deletions(-)
