pgsql: doc: Clean up title case use
doc: Clean up title case use Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/6ef762938eead1a42024b219311f6ede5dc2104a Modified Files -- doc/src/sgml/file-fdw.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Fix typo and comments related to the recent no-wait lock improve
Fix typo and comments related to the recent no-wait lock improvements The argument of dontWait at the top of ProcSleep() was documented backwards, and there was a typo in lock.c. Thinkos in 2346df6fc373. Author: Will Mortensen Reviewed-by: Jingxian Li, Michael Paquier Discussion: https://postgr.es/m/campnoc5f+eis7tdy8pupd_lacstvt-pypvookfjhrqqmkhp...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/f7ab71ba0c7bcf237403d40269aeea0a0f2551df Modified Files -- src/backend/storage/lmgr/lock.c | 2 +- src/backend/storage/lmgr/proc.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-)
pgsql: doc: Fix column_name parameter in ALTER MATERIALIZED VIEW
doc: Fix column_name parameter in ALTER MATERIALIZED VIEW Parameter column_name must be an existing column because ALTER MATERIALIZED VIEW cannot add new columns. The old description was likely copied from ALTER TABLE. Author: Erik Wienhold Discussion: https://postgr.es/m/6880ca53-7961-4eeb-86d5-6bd05fc20...@ewie.name Backpatch-through: 12 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/dd087e1c13bf5f2bcfdc189976aa4e44ed431739 Modified Files -- doc/src/sgml/ref/alter_materialized_view.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: doc: Fix column_name parameter in ALTER MATERIALIZED VIEW
doc: Fix column_name parameter in ALTER MATERIALIZED VIEW Parameter column_name must be an existing column because ALTER MATERIALIZED VIEW cannot add new columns. The old description was likely copied from ALTER TABLE. Author: Erik Wienhold Discussion: https://postgr.es/m/6880ca53-7961-4eeb-86d5-6bd05fc20...@ewie.name Backpatch-through: 12 Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c0acf25a5cf2d62b60d82e5bb0c553ce9c05a51d Modified Files -- doc/src/sgml/ref/alter_materialized_view.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: doc: Fix column_name parameter in ALTER MATERIALIZED VIEW
doc: Fix column_name parameter in ALTER MATERIALIZED VIEW Parameter column_name must be an existing column because ALTER MATERIALIZED VIEW cannot add new columns. The old description was likely copied from ALTER TABLE. Author: Erik Wienhold Discussion: https://postgr.es/m/6880ca53-7961-4eeb-86d5-6bd05fc20...@ewie.name Backpatch-through: 12 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0c6b6498131e0552d5bb120bdcbf72ffbcd524fa Modified Files -- doc/src/sgml/ref/alter_materialized_view.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: doc: Fix column_name parameter in ALTER MATERIALIZED VIEW
doc: Fix column_name parameter in ALTER MATERIALIZED VIEW Parameter column_name must be an existing column because ALTER MATERIALIZED VIEW cannot add new columns. The old description was likely copied from ALTER TABLE. Author: Erik Wienhold Discussion: https://postgr.es/m/6880ca53-7961-4eeb-86d5-6bd05fc20...@ewie.name Backpatch-through: 12 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c0df15ac7e9ef3870da50fde49c658290f7a0da6 Modified Files -- doc/src/sgml/ref/alter_materialized_view.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: doc: Fix column_name parameter in ALTER MATERIALIZED VIEW
doc: Fix column_name parameter in ALTER MATERIALIZED VIEW Parameter column_name must be an existing column because ALTER MATERIALIZED VIEW cannot add new columns. The old description was likely copied from ALTER TABLE. Author: Erik Wienhold Discussion: https://postgr.es/m/6880ca53-7961-4eeb-86d5-6bd05fc20...@ewie.name Backpatch-through: 12 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/961608636461e259487223237147ce447672deaa Modified Files -- doc/src/sgml/ref/alter_materialized_view.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: doc: Fix column_name parameter in ALTER MATERIALIZED VIEW
doc: Fix column_name parameter in ALTER MATERIALIZED VIEW Parameter column_name must be an existing column because ALTER MATERIALIZED VIEW cannot add new columns. The old description was likely copied from ALTER TABLE. Author: Erik Wienhold Discussion: https://postgr.es/m/6880ca53-7961-4eeb-86d5-6bd05fc20...@ewie.name Backpatch-through: 12 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b4f808467a56b69838730164df5a22f946087b82 Modified Files -- doc/src/sgml/ref/alter_materialized_view.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Fix a couple of outdated comments now that we have MERGE RETURNI
Fix a couple of outdated comments now that we have MERGE RETURNING This has been supported since c649fa24a. Discussion: https://postgr.es/m/caaphdvpqp6vtuzg-_josueibgyqnrnvxj-vdf+hjlxjhdhz...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8559252095e17c3cf25a28921a6ef8a14e769519 Modified Files -- src/include/nodes/plannodes.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
pgsql: Don't copy extended statistics during MERGE/SPLIT partition oper
Don't copy extended statistics during MERGE/SPLIT partition operations When MERGE/SPLIT created new partitions, it was cloning the extended statistics of the parent table. However, extended stats on partitioned tables don't behave like indexes on partitioned tables (which exist only to create physical indexes on child tables). Rather, extended stats on a parent 1) cause extended stats to be collected and computed across the whole partition hierarchy, and 2) do not cause extended stats to be computed for the individual partitions. "CREATE TABLE ... PARTITION OF" command doesn't copy extended statistics. This commit makes createPartitionTable() behave consistently. Reported-by: Justin Pryzby Discussion: https://postgr.es/m/ZiJW1g2nbQs9ekwK%40pryzbyj2023 Author: Alexander Korotkov, Justin Pryzby Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/fbd4321fd5b4400fbbf356d686af6ad6d3208c66 Modified Files -- doc/src/sgml/ref/alter_table.sgml | 9 +++-- src/backend/commands/tablecmds.c | 8 +--- 2 files changed, 12 insertions(+), 5 deletions(-)
pgsql: Fix the name collision detection in MERGE/SPLIT partition operat
Fix the name collision detection in MERGE/SPLIT partition operations Both MERGE and SPLIT partition operations support the case when the name of the new partition matches the name of the existing partition to be merged/split. But the name collision detection doesn't always work as intended. The SPLIT partition operation finds the namespace to search for an existing partition without taking into account the parent's persistence. The MERGE partition operation checks for the name collision with simple equal() on RangeVar's simply ignoring the search_path. This commit fixes this behavior as follows. 1. The SPLIT partition operation now finds the namespace to search for an existing partition according to the parent's persistence. 2. The MERGE partition operation now checks for the name collision similarly to the SPLIT partition operation using RangeVarGetAndCheckCreationNamespace() and get_relname_relid(). Reported-by: Alexander Lakhin Discussion: https://postgr.es/m/86b4f1e3-0b5d-315c-9225-19860d64d685%40gmail.com Author: Dmitry Koval, Alexander Korotkov Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/3a82c689fd1be9bdf9d60135e5db7d352c051269 Modified Files -- src/backend/commands/tablecmds.c | 62 ++- src/test/regress/expected/partition_merge.out | 3 +- src/test/regress/expected/partition_split.out | 8 src/test/regress/sql/partition_merge.sql | 3 +- src/test/regress/sql/partition_split.sql | 9 5 files changed, 72 insertions(+), 13 deletions(-)
pgsql: amcheck: Don't load the right sibling page into BtreeCheckState
amcheck: Don't load the right sibling page into BtreeCheckState 5ae2087202 implemented a cross-page unique constraint check by loading the right sibling to the BtreeCheckState.target variable. This is wrong, because bt_target_page_check() shouldn't change the target page. Also, BtreeCheckState.target shouldn't be changed alone without BtreeCheckState.targetblock. However, the above didn't cause any visible bugs for the following reasons. 1. We do a cross-page unique constraint check only for leaf index pages. 2. The only way target page get accessed after a cross-page unique constraint check is loading of the lowkey. 3. The only place lowkey is used is bt_child_highkey_check(), and that applies only to non-leafs. The reasons above don't diminish the fact that changing BtreeCheckState.target for a cross-page unique constraint check is wrong. This commit changes this check to temporarily store the right sibling to the local variable. Reported-by: Peter Geoghegan Discussion: https://postgr.es/m/CAH2-Wzk%2B2116uOXdOViA27SHcr31WKPgmjsxXLBs_aTxAeThzg%40mail.gmail.com Author: Pavel Borisov Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0b5c161248110b164a006004c78f9529a109 Modified Files -- contrib/amcheck/verify_nbtree.c | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-)
pgsql: amcheck: Refactoring the storage of the last visible entry
amcheck: Refactoring the storage of the last visible entry This commit introduces a new data structure BtreeLastVisibleEntry comprising information about the last visible heap entry with the current value of key. Usage of this data structure allows us to avoid passing all this information as individual function arguments. Reported-by: Alexander Korotkov Discussion: https://www.postgresql.org/message-id/CAPpHfdsVbB9ToriaB1UHuOKwjKxiZmTFQcEF%3DjuzzC_nby31uA%40mail.gmail.com Author: Pavel Borisov, Alexander Korotkov Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/532d94fec32ac11263b53932365560491d1fd50a Modified Files -- contrib/amcheck/verify_nbtree.c | 117 --- src/tools/pgindent/typedefs.list | 1 + 2 files changed, 60 insertions(+), 58 deletions(-)
pgsql: amcheck: Report an error when the next page to a leaf is not a l
amcheck: Report an error when the next page to a leaf is not a leaf This is a very unlikely condition during checking a B-tree unique constraint, meaning that the index structure is violated badly, and we shouldn't continue checking to avoid endless loops, etc. So it's worth immediately throwing an error. Reported-by: Peter Geoghegan Discussion: https://postgr.es/m/CAH2-Wzk%2B2116uOXdOViA27SHcr31WKPgmjsxXLBs_aTxAeThzg%40mail.gmail.com Author: Pavel Borisov Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/97e5b0026fc276ab1bcde58ae98ae1fcd9c3acc3 Modified Files -- contrib/amcheck/verify_nbtree.c | 22 -- 1 file changed, 16 insertions(+), 6 deletions(-)
pgsql: doc PG 17 relnotes: fix pg_stat_reset_shared quoting
doc PG 17 relnotes: fix pg_stat_reset_shared quoting Reported-by: torikoshia Discussion: https://postgr.es/m/8ab708436c369d47fcbb23a8ad775...@oss.nttdata.com Backpatch-through: master Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/bac44bc29a64d882e9717672ff788f19e3d2eb1d Modified Files -- doc/src/sgml/release-17.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: doc PG 17 relnotes: fix pg_stat_statements typo
doc PG 17 relnotes: fix pg_stat_statements typo Reported-by: Masahiko Sawada Discussion: https://postgr.es/m/CAD21AoB_MR=S_Gh=oejr4ji0ggy+d8747o-5pycbmbhgomt...@mail.gmail.com Author: Masahiko Sawada Backpatch-through: master Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d0155ba41e4204c331486cd9f4564c13987702eb Modified Files -- doc/src/sgml/release-17.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: doc PG 17 relnotes: adjust SQL/JSON constructor func. authors
doc PG 17 relnotes: adjust SQL/JSON constructor func. authors Reported-by: Amit Langote Discussion: https://postgr.es/m/CA+HiwqHA2_2V-UtdEEjX3wMUcO=pAwH2D=9p9crygvcnljk...@mail.gmail.com Author: Amit Langote Backpatch-through: master Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/29a9a632c5b37c5a27e173496959bd162419b155 Modified Files -- doc/src/sgml/release-17.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: doc PG 17 relnotes: adjust builtin collation provider item
doc PG 17 relnotes: adjust builtin collation provider item Reported-by: Jeff Davis Discussion: https://postgr.es/m/92e039f6fabc3567169e95e12b39a04c00f8503b.ca...@j-davis.com Backpatch-through: master Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/3551da969e8d4ca392de1dd7b43c46dbf3ba2ec1 Modified Files -- doc/src/sgml/release-17.sgml | 4 ++-- 1 file changed, 2 insertions(+), 2 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: doc PG 17 relnotes: add Heikki Linnakangas to vacuum item
doc PG 17 relnotes: add Heikki Linnakangas to vacuum item Reported-by: Melanie Plageman Discussion: https://postgr.es/m/caakru_yyr5mxy-xucpr7dkkugcextsjry9ax8c-z7lka8dd...@mail.gmail.com Author: Melanie Plageman Backpatch-through: master Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d2a338e0603cd218a070b236e3a9f4bcb77588e6 Modified Files -- doc/src/sgml/release-17.sgml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
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: Tag refs/tags/REL_17_BETA1 was created
Tag refs/tags/REL_17_BETA1 was created.
