Re: pgsql: Fix bogus grammar for a CREATE CONSTRAINT TRIGGER error
On 2025-Jul-03, Daniel Gustafsson wrote: > > On 3 Jul 2025, at 11:30, Álvaro Herrera wrote: > > alabio seems unhappy, and the hunk below seems to be culprit, it should closed > with a right? Thanks for pointing this out. Yeah, not only I used the wrong tag, but it's also missing the wrapping around the text. Should be fixed now. It turns out our meson port doesn't have the equivalent of a "make -C doc/src/sgml check". Sigh. Back to configure again for me ... -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "Industry suffers from the managerial dogma that for the sake of stability and continuity, the company should be independent of the competence of individual employees." (E. Dijkstra)
pgsql: Fix bogus grammar for a CREATE CONSTRAINT TRIGGER error
Fix bogus grammar for a CREATE CONSTRAINT TRIGGER error If certain constraint characteristic clauses (NO INHERIT, NOT VALID, NOT ENFORCED) are given to CREATE CONSTRAINT TRIGGER, the resulting error message is ERROR: TRIGGER constraints cannot be marked NO INHERIT which is a bit silly, because these aren't "constraints of type TRIGGER". Hardcode a better error message to prevent it. This is a cosmetic fix for quite a fringe problem with no known complaints from users, so no backpatch. While at it, silently accept ENFORCED if given. Author: Amul Sul Reviewed-by: jian he Reviewed-by: Fujii Masao Reviewed-by: Álvaro Herrera Discussion: https://postgr.es/m/caaj_b97hd-jmts7ajgu6tdbczdx_kyukxg+k-dtymoieg+g...@mail.gmail.com Discussion: https://postgr.es/m/CACJufxHSp2puxP=q8ztugl1f+heapnzqfbzy5zngujugwjb...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/87251e114967d668c8f90ed9fb8c8a8834c2d288 Modified Files -- doc/src/sgml/ref/create_trigger.sgml | 9 - src/backend/parser/gram.y | 22 +- src/test/regress/expected/triggers.out | 23 ++- src/test/regress/sql/triggers.sql | 15 ++- 4 files changed, 65 insertions(+), 4 deletions(-)
pgsql: doc: Update outdated descriptions of wal_status in pg_replicatio
doc: Update outdated descriptions of wal_status in pg_replication_slots. The documentation for pg_replication_slots previously mentioned only max_slot_wal_keep_size as a condition under which the wal_status column could show unreserved or lost. However, since commit be87200, replication slots can also be invalidated due to horizon or wal_level, and since commit ac0e33136ab, idle_replication_slot_timeout can also trigger this state. This commit updates the description of the wal_status column to reflect that max_slot_wal_keep_size is not the only cause of the lost state. Back-patched to v16, where the additional invalidation cases were introduced. Author: Fujii Masao Reviewed-by: Hayato Kuroda Reviewed-by: Nisha Moond Discussion: https://postgr.es/m/78b34e84-2195-4f28-a151-5d204a382...@oss.nttdata.com Backpatch-through: 16 Branch -- REL_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/0cd7fcaa857400fff28e31f0538d7824814c6863 Modified Files -- doc/src/sgml/system-views.sgml | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-)
pgsql: doc: Update outdated descriptions of wal_status in pg_replicatio
doc: Update outdated descriptions of wal_status in pg_replication_slots. The documentation for pg_replication_slots previously mentioned only max_slot_wal_keep_size as a condition under which the wal_status column could show unreserved or lost. However, since commit be87200, replication slots can also be invalidated due to horizon or wal_level, and since commit ac0e33136ab, idle_replication_slot_timeout can also trigger this state. This commit updates the description of the wal_status column to reflect that max_slot_wal_keep_size is not the only cause of the lost state. Back-patched to v16, where the additional invalidation cases were introduced. Author: Fujii Masao Reviewed-by: Hayato Kuroda Reviewed-by: Nisha Moond Discussion: https://postgr.es/m/78b34e84-2195-4f28-a151-5d204a382...@oss.nttdata.com Backpatch-through: 16 Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ba9201b57b00b8f9a612a3fd1ae22a768556cb3d Modified Files -- doc/src/sgml/system-views.sgml | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-)
pgsql: doc: Update outdated descriptions of wal_status in pg_replicatio
doc: Update outdated descriptions of wal_status in pg_replication_slots. The documentation for pg_replication_slots previously mentioned only max_slot_wal_keep_size as a condition under which the wal_status column could show unreserved or lost. However, since commit be87200, replication slots can also be invalidated due to horizon or wal_level, and since commit ac0e33136ab, idle_replication_slot_timeout can also trigger this state. This commit updates the description of the wal_status column to reflect that max_slot_wal_keep_size is not the only cause of the lost state. Back-patched to v16, where the additional invalidation cases were introduced. Author: Fujii Masao Reviewed-by: Hayato Kuroda Reviewed-by: Nisha Moond Discussion: https://postgr.es/m/78b34e84-2195-4f28-a151-5d204a382...@oss.nttdata.com Backpatch-through: 16 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ff3007c66dc6213fcdaea9a996865bbd943e3e82 Modified Files -- doc/src/sgml/system-views.sgml | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-)
pgsql: doc: Update outdated descriptions of wal_status in pg_replicatio
doc: Update outdated descriptions of wal_status in pg_replication_slots. The documentation for pg_replication_slots previously mentioned only max_slot_wal_keep_size as a condition under which the wal_status column could show unreserved or lost. However, since commit be87200, replication slots can also be invalidated due to horizon or wal_level, and since commit ac0e33136ab, idle_replication_slot_timeout can also trigger this state. This commit updates the description of the wal_status column to reflect that max_slot_wal_keep_size is not the only cause of the lost state. Back-patched to v16, where the additional invalidation cases were introduced. Author: Fujii Masao Reviewed-by: Hayato Kuroda Reviewed-by: Nisha Moond Discussion: https://postgr.es/m/78b34e84-2195-4f28-a151-5d204a382...@oss.nttdata.com Backpatch-through: 16 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/db51bdf975e28003f08013a12bc46c0848533edc Modified Files -- doc/src/sgml/system-views.sgml | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-)
pgsql: Simplify COALESCE() with one surviving argument.
Simplify COALESCE() with one surviving argument. If, after removal of useless null-constant arguments, a CoalesceExpr has exactly one remaining argument, we can just take that argument as the result, without bothering to wrap a new CoalesceExpr around it. This isn't likely to produce any great improvement in runtime per se, but it can lead to better plans since the planner no longer has to treat the expression as non-strict. However, there were a few regression test cases that intentionally wrote COALESCE(x) as a shorthand way of creating a non-strict subexpression. To avoid ruining the intent of those tests, write COALESCE(x,x) instead. (If anyone ever proposes de-duplicating COALESCE arguments, we'll need another iteration of this arms race. But it seems pretty unlikely that such an optimization would be worthwhile.) Author: Maksim Milyutin Reviewed-by: Tom Lane Discussion: https://postgr.es/m/8e8573c3-1411-448d-877e-53258b7b2...@tantorlabs.ru Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/931766aaec58b2ce09c82203456877e0b05e1271 Modified Files -- src/backend/optimizer/util/clauses.c| 7 + src/test/regress/expected/join.out | 32 +++ src/test/regress/expected/subselect.out | 46 - src/test/regress/sql/join.sql | 10 +++ src/test/regress/sql/subselect.sql | 8 +++--- 5 files changed, 55 insertions(+), 48 deletions(-)
pgsql: Remove leftover dead code from commit_ts.h.
Remove leftover dead code from commit_ts.h. Commit 08aa89b3262 removed the COMMIT_TS_SETTS WAL record, leaving xl_commit_ts_set and SizeOfCommitTsSet unused. However, it missed removing these definitions. This commit cleans up the leftover code. Since this is a cleanup rather than a bug fix, it is applied only to the master branch. Author: Andy Fan Reviewed-by: Fujii Masao Discussion: https://postgr.es/m/87ecuzmkqf@163.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c84698ceaea8a08b1d11d527ce9530a98b156799 Modified Files -- src/include/access/commit_ts.h | 11 --- 1 file changed, 11 deletions(-)
pgsql: Fix broken XML
Fix broken XML I messed this up in commit 87251e114967. Per buildfarm member alabio, via Daniel Gustafsson. Discussion: https://postgr.es/m/b94d82d1-7af4-4412-ac02-82eaa6154...@yesql.se Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/81a2625eb2e4608ba6ca41b2bf548dce8d81ced7 Modified Files -- doc/src/sgml/ref/create_trigger.sgml | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-)
pgsql: Add more cross-type comparisons to contrib/btree_gin.
Add more cross-type comparisons to contrib/btree_gin. Using the just-added infrastructure, extend btree_gin to support cross-type operators in its other opclasses. All of the cross-type comparison operators supported by the core btree opclasses for these datatypes are now available for btree_gin indexes as well. Author: Tom Lane Reviewed-by: Arseniy Mukhin Discussion: https://postgr.es/m/262624.1738460...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/fc896821c4448038c5cc678c1aff7349ee850b23 Modified Files -- contrib/btree_gin/btree_gin--1.3--1.4.sql | 88 +++ contrib/btree_gin/btree_gin.c | 192 +-- contrib/btree_gin/expected/date.out| 362 + contrib/btree_gin/expected/float4.out | 321 + contrib/btree_gin/expected/float8.out | 50 contrib/btree_gin/expected/name.out| 59 + contrib/btree_gin/expected/text.out| 50 contrib/btree_gin/expected/timestamp.out | 306 +++- contrib/btree_gin/expected/timestamptz.out | 111 - contrib/btree_gin/sql/date.sql | 64 + contrib/btree_gin/sql/float4.sql | 53 + contrib/btree_gin/sql/float8.sql | 9 + contrib/btree_gin/sql/name.sql | 11 + contrib/btree_gin/sql/text.sql | 9 + contrib/btree_gin/sql/timestamp.sql| 55 - contrib/btree_gin/sql/timestamptz.sql | 22 +- 16 files changed, 1725 insertions(+), 37 deletions(-)
pgsql: Break out xxx2yyy_opt_overflow APIs for more datetime conversion
Break out xxx2yyy_opt_overflow APIs for more datetime conversions. Previous commits invented timestamp2timestamptz_opt_overflow, date2timestamp_opt_overflow, and date2timestamptz_opt_overflow functions to perform non-error-throwing conversions between datetime types. This patch completes the set by adding timestamp2date_opt_overflow, timestamptz2date_opt_overflow, and timestamptz2timestamp_opt_overflow. In addition, adjust timestamp2timestamptz_opt_overflow so that it doesn't throw error if timestamp2tm fails, but treats that as an overflow case. The situation probably can't arise except with an invalid timestamp value, and I can't think of a way that that would happen except data corruption. However, it's pretty silly to have a function whose entire reason for existence is to not throw errors for out-of-range inputs nonetheless throw an error for out-of-range input. The new APIs are not used in this patch, but will be needed in upcoming btree_gin changes. Author: Tom Lane Reviewed-by: Arseniy Mukhin Discussion: https://postgr.es/m/262624.1738460...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0059bbe1ecaa5f7f19a8b3aae059f352c02e1d88 Modified Files -- src/backend/utils/adt/date.c | 86 ++- src/backend/utils/adt/timestamp.c | 81 +--- src/include/utils/date.h | 2 + src/include/utils/timestamp.h | 3 ++ 4 files changed, 156 insertions(+), 16 deletions(-)
pgsql: Add cross-type comparisons to contrib/btree_gin.
Add cross-type comparisons to contrib/btree_gin. Extend the infrastructure in btree_gin.c to permit cross-type operators, and add the code to support them for the int2, int4, and int8 opclasses. (To keep this patch digestible, I left the other datatypes for a separate patch.) This improves the usability of btree_gin indexes by allowing them to support the same set of queries that a regular btree index does. Author: Tom Lane Reviewed-by: Arseniy Mukhin Discussion: https://postgr.es/m/262624.1738460...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e2b64fcef35f70f96fa92db56fbfa9ac2da136c7 Modified Files -- contrib/btree_gin/Makefile| 2 +- contrib/btree_gin/btree_gin--1.3--1.4.sql | 63 contrib/btree_gin/btree_gin.c | 479 +- contrib/btree_gin/btree_gin.control | 2 +- contrib/btree_gin/expected/int2.out | 190 contrib/btree_gin/expected/int4.out | 100 +++ contrib/btree_gin/expected/int8.out | 100 +++ contrib/btree_gin/meson.build | 1 + contrib/btree_gin/sql/int2.sql| 35 +++ contrib/btree_gin/sql/int4.sql| 18 ++ contrib/btree_gin/sql/int8.sql| 18 ++ doc/src/sgml/gin.sgml | 6 +- src/tools/pgindent/typedefs.list | 2 + 13 files changed, 931 insertions(+), 85 deletions(-)
pgsql: Add tab-completion for ALTER TABLE not-nulls
Add tab-completion for ALTER TABLE not-nulls The command is: ALTER TABLE x ADD [CONSTRAINT y] NOT NULL z This syntax was added in 18, but I got pushback for getting commit dbf42b84ac7b in 18 (also tab-completion for new syntax) after the feature freeze, so I'll put this in master only for now. Author: Álvaro Herrera Reported-by: Fujii Masao Reviewed-by: Fujii Masao Reviewed-by: Dagfinn Ilmari Mannsåker Discussion: https://postgr.es/m/d4f14c6b-086b-463c-b15f-01c7c9728...@oss.nttdata.com Discussion: https://postgr.es/m/202505111448.bwbfomrymq4b@alvherre.pgsql Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a604affaded028b6bfba024127931289c2b756c2 Modified Files -- src/bin/psql/tab-complete.in.c | 17 - 1 file changed, 12 insertions(+), 5 deletions(-)
pgsql: Obtain required table lock during cross-table updates, redux.
Obtain required table lock during cross-table updates, redux. Commits 8319e5cb5 et al missed the fact that ATPostAlterTypeCleanup contains three calls to ATPostAlterTypeParse, and the other two also need protection against passing a relid that we don't yet have lock on. Add similar logic to those code paths, and add some test cases demonstrating the need for it. In v18 and master, the test cases demonstrate that there's a behavioral discrepancy between stored generated columns and virtual generated columns: we disallow changing the expression of a stored column if it's used in any composite-type columns, but not that of a virtual column. Since the expression isn't actually relevant to either sort of composite-type usage, this prohibition seems unnecessary; but changing it is a matter for separate discussion. For now we are just documenting the existing behavior. Reported-by: jian he Author: jian he Reviewed-by: Tom Lane Discussion: CACJufxGKJtGNRRSXfwMW9SqVOPEMdP17BJ7DsBf=tnsv9pw...@mail.gmail.com Backpatch-through: 13 Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/6d4395b4021d5f2640f2aadece1dad650b1e7037 Modified Files -- src/backend/commands/tablecmds.c | 22 ++ src/test/regress/expected/alter_table.out | 8 src/test/regress/expected/generated.out | 24 src/test/regress/sql/alter_table.sql | 8 src/test/regress/sql/generated.sql| 25 + 5 files changed, 87 insertions(+)
pgsql: Obtain required table lock during cross-table updates, redux.
Obtain required table lock during cross-table updates, redux. Commits 8319e5cb5 et al missed the fact that ATPostAlterTypeCleanup contains three calls to ATPostAlterTypeParse, and the other two also need protection against passing a relid that we don't yet have lock on. Add similar logic to those code paths, and add some test cases demonstrating the need for it. In v18 and master, the test cases demonstrate that there's a behavioral discrepancy between stored generated columns and virtual generated columns: we disallow changing the expression of a stored column if it's used in any composite-type columns, but not that of a virtual column. Since the expression isn't actually relevant to either sort of composite-type usage, this prohibition seems unnecessary; but changing it is a matter for separate discussion. For now we are just documenting the existing behavior. Reported-by: jian he Author: jian he Reviewed-by: Tom Lane Discussion: CACJufxGKJtGNRRSXfwMW9SqVOPEMdP17BJ7DsBf=tnsv9pw...@mail.gmail.com Backpatch-through: 13 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e902f818191fb7adce9d3d14150f56e528662fa9 Modified Files -- src/backend/commands/tablecmds.c | 22 ++ src/test/regress/expected/alter_table.out | 8 src/test/regress/sql/alter_table.sql | 8 3 files changed, 38 insertions(+)
pgsql: Obtain required table lock during cross-table updates, redux.
Obtain required table lock during cross-table updates, redux. Commits 8319e5cb5 et al missed the fact that ATPostAlterTypeCleanup contains three calls to ATPostAlterTypeParse, and the other two also need protection against passing a relid that we don't yet have lock on. Add similar logic to those code paths, and add some test cases demonstrating the need for it. In v18 and master, the test cases demonstrate that there's a behavioral discrepancy between stored generated columns and virtual generated columns: we disallow changing the expression of a stored column if it's used in any composite-type columns, but not that of a virtual column. Since the expression isn't actually relevant to either sort of composite-type usage, this prohibition seems unnecessary; but changing it is a matter for separate discussion. For now we are just documenting the existing behavior. Reported-by: jian he Author: jian he Reviewed-by: Tom Lane Discussion: CACJufxGKJtGNRRSXfwMW9SqVOPEMdP17BJ7DsBf=tnsv9pw...@mail.gmail.com Backpatch-through: 13 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e6dd6e6ee6e1443441088173231fe9085ce4b912 Modified Files -- src/backend/commands/tablecmds.c | 22 ++ src/test/regress/expected/alter_table.out | 8 src/test/regress/sql/alter_table.sql | 8 3 files changed, 38 insertions(+)
pgsql: Obtain required table lock during cross-table updates, redux.
Obtain required table lock during cross-table updates, redux. Commits 8319e5cb5 et al missed the fact that ATPostAlterTypeCleanup contains three calls to ATPostAlterTypeParse, and the other two also need protection against passing a relid that we don't yet have lock on. Add similar logic to those code paths, and add some test cases demonstrating the need for it. In v18 and master, the test cases demonstrate that there's a behavioral discrepancy between stored generated columns and virtual generated columns: we disallow changing the expression of a stored column if it's used in any composite-type columns, but not that of a virtual column. Since the expression isn't actually relevant to either sort of composite-type usage, this prohibition seems unnecessary; but changing it is a matter for separate discussion. For now we are just documenting the existing behavior. Reported-by: jian he Author: jian he Reviewed-by: Tom Lane Discussion: CACJufxGKJtGNRRSXfwMW9SqVOPEMdP17BJ7DsBf=tnsv9pw...@mail.gmail.com Backpatch-through: 13 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a10f21e6ce549705f194b8fdb28e685403e7579d Modified Files -- src/backend/commands/tablecmds.c| 22 ++ src/test/regress/expected/alter_table.out | 8 src/test/regress/expected/generated_stored.out | 12 src/test/regress/expected/generated_virtual.out | 9 + src/test/regress/sql/alter_table.sql| 8 src/test/regress/sql/generated_stored.sql | 13 + src/test/regress/sql/generated_virtual.sql | 13 + 7 files changed, 85 insertions(+)
pgsql: Obtain required table lock during cross-table updates, redux.
Obtain required table lock during cross-table updates, redux. Commits 8319e5cb5 et al missed the fact that ATPostAlterTypeCleanup contains three calls to ATPostAlterTypeParse, and the other two also need protection against passing a relid that we don't yet have lock on. Add similar logic to those code paths, and add some test cases demonstrating the need for it. In v18 and master, the test cases demonstrate that there's a behavioral discrepancy between stored generated columns and virtual generated columns: we disallow changing the expression of a stored column if it's used in any composite-type columns, but not that of a virtual column. Since the expression isn't actually relevant to either sort of composite-type usage, this prohibition seems unnecessary; but changing it is a matter for separate discussion. For now we are just documenting the existing behavior. Reported-by: jian he Author: jian he Reviewed-by: Tom Lane Discussion: CACJufxGKJtGNRRSXfwMW9SqVOPEMdP17BJ7DsBf=tnsv9pw...@mail.gmail.com Backpatch-through: 13 Branch -- REL_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/3d7a96871c71dc0e6d2614eb4a68179bc7e383db Modified Files -- src/backend/commands/tablecmds.c| 22 ++ src/test/regress/expected/alter_table.out | 8 src/test/regress/expected/generated_stored.out | 12 src/test/regress/expected/generated_virtual.out | 9 + src/test/regress/sql/alter_table.sql| 8 src/test/regress/sql/generated_stored.sql | 13 + src/test/regress/sql/generated_virtual.sql | 13 + 7 files changed, 85 insertions(+)
pgsql: Obtain required table lock during cross-table updates, redux.
Obtain required table lock during cross-table updates, redux. Commits 8319e5cb5 et al missed the fact that ATPostAlterTypeCleanup contains three calls to ATPostAlterTypeParse, and the other two also need protection against passing a relid that we don't yet have lock on. Add similar logic to those code paths, and add some test cases demonstrating the need for it. In v18 and master, the test cases demonstrate that there's a behavioral discrepancy between stored generated columns and virtual generated columns: we disallow changing the expression of a stored column if it's used in any composite-type columns, but not that of a virtual column. Since the expression isn't actually relevant to either sort of composite-type usage, this prohibition seems unnecessary; but changing it is a matter for separate discussion. For now we are just documenting the existing behavior. Reported-by: jian he Author: jian he Reviewed-by: Tom Lane Discussion: CACJufxGKJtGNRRSXfwMW9SqVOPEMdP17BJ7DsBf=tnsv9pw...@mail.gmail.com Backpatch-through: 13 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f9ba071cc5bdd2a98c361b5a75e995ffaa0ec787 Modified Files -- src/backend/commands/tablecmds.c | 8 src/test/regress/expected/alter_table.out | 4 src/test/regress/sql/alter_table.sql | 4 3 files changed, 16 insertions(+)
pgsql: Obtain required table lock during cross-table updates, redux.
Obtain required table lock during cross-table updates, redux. Commits 8319e5cb5 et al missed the fact that ATPostAlterTypeCleanup contains three calls to ATPostAlterTypeParse, and the other two also need protection against passing a relid that we don't yet have lock on. Add similar logic to those code paths, and add some test cases demonstrating the need for it. In v18 and master, the test cases demonstrate that there's a behavioral discrepancy between stored generated columns and virtual generated columns: we disallow changing the expression of a stored column if it's used in any composite-type columns, but not that of a virtual column. Since the expression isn't actually relevant to either sort of composite-type usage, this prohibition seems unnecessary; but changing it is a matter for separate discussion. For now we are just documenting the existing behavior. Reported-by: jian he Author: jian he Reviewed-by: Tom Lane Discussion: CACJufxGKJtGNRRSXfwMW9SqVOPEMdP17BJ7DsBf=tnsv9pw...@mail.gmail.com Backpatch-through: 13 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d36980b7159a343ec56baca40bfe6c67765095b7 Modified Files -- src/backend/commands/tablecmds.c | 22 ++ src/test/regress/expected/alter_table.out | 8 src/test/regress/sql/alter_table.sql | 8 3 files changed, 38 insertions(+)
Re: pgsql: Fix bogus grammar for a CREATE CONSTRAINT TRIGGER error
> On 3 Jul 2025, at 11:30, Álvaro Herrera wrote: alabio seems unhappy, and the hunk below seems to be culprit, it should closed with a right? > doc/src/sgml/ref/create_trigger.sgml | 9 - + +ENFORCED + + This is a noise word. Constraint triggers are always enforced. + + -- Daniel Gustafsson
pgsql: doc: Remove incorrect note about wal_status in pg_replication_sl
doc: Remove incorrect note about wal_status in pg_replication_slots. The documentation previously stated that the wal_status column is NULL if restart_lsn is NULL in the pg_replication_slots view. This is incorrect, and wal_status can be "lost" even when restart_lsn is NULL. This commit removes the incorrect description. Back-patched to all supported versions. Author: Fujii Masao Reviewed-by: Nisha Moond Discussion: https://postgr.es/m/c9d23cdc-b5dd-455a-8ee9-f1f24d701...@oss.nttdata.com Backpatch-through: 13 Branch -- REL_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f0151e2a4ef13949b4402b9d7ee0f45209cc0126 Modified Files -- doc/src/sgml/system-views.sgml | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
pgsql: doc: Remove incorrect note about wal_status in pg_replication_sl
doc: Remove incorrect note about wal_status in pg_replication_slots. The documentation previously stated that the wal_status column is NULL if restart_lsn is NULL in the pg_replication_slots view. This is incorrect, and wal_status can be "lost" even when restart_lsn is NULL. This commit removes the incorrect description. Back-patched to all supported versions. Author: Fujii Masao Reviewed-by: Nisha Moond Discussion: https://postgr.es/m/c9d23cdc-b5dd-455a-8ee9-f1f24d701...@oss.nttdata.com Backpatch-through: 13 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/170673a22f28bd6a1d3fa56e23cd74dcbcb60c17 Modified Files -- doc/src/sgml/system-views.sgml | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
pgsql: doc: Remove incorrect note about wal_status in pg_replication_sl
doc: Remove incorrect note about wal_status in pg_replication_slots. The documentation previously stated that the wal_status column is NULL if restart_lsn is NULL in the pg_replication_slots view. This is incorrect, and wal_status can be "lost" even when restart_lsn is NULL. This commit removes the incorrect description. Back-patched to all supported versions. Author: Fujii Masao Reviewed-by: Nisha Moond Discussion: https://postgr.es/m/c9d23cdc-b5dd-455a-8ee9-f1f24d701...@oss.nttdata.com Backpatch-through: 13 Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/27224e660aca7704e565ff6d7fc1c8f262c2f05c Modified Files -- doc/src/sgml/system-views.sgml | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
pgsql: doc: Remove incorrect note about wal_status in pg_replication_sl
doc: Remove incorrect note about wal_status in pg_replication_slots. The documentation previously stated that the wal_status column is NULL if restart_lsn is NULL in the pg_replication_slots view. This is incorrect, and wal_status can be "lost" even when restart_lsn is NULL. This commit removes the incorrect description. Back-patched to all supported versions. Author: Fujii Masao Reviewed-by: Nisha Moond Discussion: https://postgr.es/m/c9d23cdc-b5dd-455a-8ee9-f1f24d701...@oss.nttdata.com Backpatch-through: 13 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4ef4b9ba77375221c597f590cde1a1adc10453ca Modified Files -- doc/src/sgml/system-views.sgml | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
pgsql: doc: Remove incorrect note about wal_status in pg_replication_sl
doc: Remove incorrect note about wal_status in pg_replication_slots. The documentation previously stated that the wal_status column is NULL if restart_lsn is NULL in the pg_replication_slots view. This is incorrect, and wal_status can be "lost" even when restart_lsn is NULL. This commit removes the incorrect description. Back-patched to all supported versions. Author: Fujii Masao Reviewed-by: Nisha Moond Discussion: https://postgr.es/m/c9d23cdc-b5dd-455a-8ee9-f1f24d701...@oss.nttdata.com Backpatch-through: 13 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8a010df41e0248dc945efde26bc7c9d152ac24b7 Modified Files -- doc/src/sgml/system-views.sgml | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
pgsql: doc: Remove incorrect note about wal_status in pg_replication_sl
doc: Remove incorrect note about wal_status in pg_replication_slots. The documentation previously stated that the wal_status column is NULL if restart_lsn is NULL in the pg_replication_slots view. This is incorrect, and wal_status can be "lost" even when restart_lsn is NULL. This commit removes the incorrect description. Back-patched to all supported versions. Author: Fujii Masao Reviewed-by: Nisha Moond Discussion: https://postgr.es/m/c9d23cdc-b5dd-455a-8ee9-f1f24d701...@oss.nttdata.com Backpatch-through: 13 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f062e43484b0a6f8e1c0a2c2ea8b87b367e89f53 Modified Files -- doc/src/sgml/catalogs.sgml | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
pgsql: doc: Remove incorrect note about wal_status in pg_replication_sl
doc: Remove incorrect note about wal_status in pg_replication_slots. The documentation previously stated that the wal_status column is NULL if restart_lsn is NULL in the pg_replication_slots view. This is incorrect, and wal_status can be "lost" even when restart_lsn is NULL. This commit removes the incorrect description. Back-patched to all supported versions. Author: Fujii Masao Reviewed-by: Nisha Moond Discussion: https://postgr.es/m/c9d23cdc-b5dd-455a-8ee9-f1f24d701...@oss.nttdata.com Backpatch-through: 13 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4c7d2c2062001509b1dab7c54f75842ab8a8bb5e Modified Files -- doc/src/sgml/catalogs.sgml | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
pgsql: Refactor subtype field of AlterDomainStmt
Refactor subtype field of AlterDomainStmt AlterDomainStmt.subtype used characters for its subtypes of commands, SET|DROP DEFAULT|NOT NULL and ADD|DROP|VALIDATE CONSTRAINT, which were hardcoded in a couple of places of the code. The code is improved by using an enum instead, with the same character values as the original code. Note that the field was documented in parsenodes.h and that it forgot to mention 'V' (VALIDATE CONSTRAINT). Author: Quan Zongliang Reviewed-by: Peter Eisentraut Reviewed-by: wenhui qiu Reviewed-by: Tender Wang Discussion: https://postgr.es/m/41ff310b-16bd-44b9-a3ef-97e20f14b...@yeah.net Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8ec04c8577a1aa3aac4b77b2747dde30c8f9c8c6 Modified Files -- src/backend/commands/tablecmds.c | 2 +- src/backend/parser/gram.y| 14 +++--- src/backend/tcop/utility.c | 12 ++-- src/include/nodes/parsenodes.h | 19 +++ src/tools/pgindent/typedefs.list | 1 + 5 files changed, 26 insertions(+), 22 deletions(-)
pgsql: Prevent creation of duplicate not-null constraints for domains
Prevent creation of duplicate not-null constraints for domains This was previously harmless, but now that we create pg_constraint rows for those, duplicates are not welcome anymore. Backpatch to 18. Co-authored-by: jian he Co-authored-by: Álvaro Herrera Discussion: https://postgr.es/m/CACJufxFSC0mcQ82bSk58sO-WJY4P-o4N6RD2M0D=dd_u_6e...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/647cffd2f3210818f3882a1ea40cfbe0a4ea8fd7 Modified Files -- src/backend/commands/typecmds.c | 14 +++--- src/test/regress/expected/domain.out | 5 + src/test/regress/sql/domain.sql | 3 +++ 3 files changed, 19 insertions(+), 3 deletions(-)
pgsql: Prevent creation of duplicate not-null constraints for domains
Prevent creation of duplicate not-null constraints for domains This was previously harmless, but now that we create pg_constraint rows for those, duplicates are not welcome anymore. Backpatch to 18. Co-authored-by: jian he Co-authored-by: Álvaro Herrera Discussion: https://postgr.es/m/CACJufxFSC0mcQ82bSk58sO-WJY4P-o4N6RD2M0D=dd_u_6e...@mail.gmail.com Branch -- REL_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8af310b331940ff5efd19402a3f8ee5521eb821a Modified Files -- src/backend/commands/typecmds.c | 14 +++--- src/test/regress/expected/domain.out | 5 + src/test/regress/sql/domain.sql | 3 +++ 3 files changed, 19 insertions(+), 3 deletions(-)
pgsql: Speed up truncation of temporary relations.
Speed up truncation of temporary relations. Previously, truncating a temporary relation required scanning the entire local buffer pool once per relation fork to invalidate buffers. This could be slow, especially with a large local buffers, as the scan was repeated multiple times. A similar issue with regular tables (shared buffers) was addressed in commit 6d05086c0a7 by scanning the buffer pool only once for all forks. This commit applies the same optimization to temporary relations, improving truncation performance. Author: Daniil Davydov <3daniss...@gmail.com> Reviewed-by: Michael Paquier Reviewed-by: Fujii Masao Reviewed-by: Dilip Kumar Reviewed-by: Maxim Orlov Discussion: https://postgr.es/m/CAJDiXggNqsJOH7C5co4jA8nDk8vw-=sokyh5s1_tenwnc6o...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/78ebda66bf2683d42b853660757aaf16268ee3b7 Modified Files -- src/backend/storage/buffer/bufmgr.c | 8 +++- src/backend/storage/buffer/localbuf.c | 21 ++--- src/include/storage/buf_internals.h | 4 ++-- 3 files changed, 19 insertions(+), 14 deletions(-)
pgsql: Disable commit timestamps during bootstrap
Disable commit timestamps during bootstrap Attempting to use commit timestamps during bootstrapping leads to an assertion failure, that can be reached for example with an initdb -c that enables track_commit_timestamp. It makes little sense to register a commit timestamp for a BootstrapTransactionId, so let's disable the activation of the module in this case. This problem has been independently reported once by each author of this commit. Each author has proposed basically the same patch, relying on IsBootstrapProcessingMode() to skip the use of commit_ts during bootstrap. The test addition is a suggestion by me, and is applied down to v16. Author: Hayato Kuroda Author: Andy Fan Reviewed-by: Bertrand Drouvot Reviewed-by: Fujii Masao Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/oscpr01mb14966ff9e4c4145f37b937e52f5...@oscpr01mb14966.jpnprd01.prod.outlook.com Discussion: https://postgr.es/m/87plejmnpy@163.com Backpatch-through: 13 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/5a6c39b6df3313e5c2d3aed714a56f5a5c6be3f2 Modified Files -- src/backend/access/transam/commit_ts.c | 7 +++ src/test/modules/commit_ts/t/001_base.pl | 3 +-- 2 files changed, 8 insertions(+), 2 deletions(-)
pgsql: Disable commit timestamps during bootstrap
Disable commit timestamps during bootstrap Attempting to use commit timestamps during bootstrapping leads to an assertion failure, that can be reached for example with an initdb -c that enables track_commit_timestamp. It makes little sense to register a commit timestamp for a BootstrapTransactionId, so let's disable the activation of the module in this case. This problem has been independently reported once by each author of this commit. Each author has proposed basically the same patch, relying on IsBootstrapProcessingMode() to skip the use of commit_ts during bootstrap. The test addition is a suggestion by me, and is applied down to v16. Author: Hayato Kuroda Author: Andy Fan Reviewed-by: Bertrand Drouvot Reviewed-by: Fujii Masao Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/oscpr01mb14966ff9e4c4145f37b937e52f5...@oscpr01mb14966.jpnprd01.prod.outlook.com Discussion: https://postgr.es/m/87plejmnpy@163.com Backpatch-through: 13 Branch -- REL_17_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ae20c105f0b20c80a6f57d43cf0ae118d0f53d7f Modified Files -- src/backend/access/transam/commit_ts.c | 7 +++ src/test/modules/commit_ts/t/001_base.pl | 3 +-- 2 files changed, 8 insertions(+), 2 deletions(-)
pgsql: Disable commit timestamps during bootstrap
Disable commit timestamps during bootstrap Attempting to use commit timestamps during bootstrapping leads to an assertion failure, that can be reached for example with an initdb -c that enables track_commit_timestamp. It makes little sense to register a commit timestamp for a BootstrapTransactionId, so let's disable the activation of the module in this case. This problem has been independently reported once by each author of this commit. Each author has proposed basically the same patch, relying on IsBootstrapProcessingMode() to skip the use of commit_ts during bootstrap. The test addition is a suggestion by me, and is applied down to v16. Author: Hayato Kuroda Author: Andy Fan Reviewed-by: Bertrand Drouvot Reviewed-by: Fujii Masao Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/oscpr01mb14966ff9e4c4145f37b937e52f5...@oscpr01mb14966.jpnprd01.prod.outlook.com Discussion: https://postgr.es/m/87plejmnpy@163.com Backpatch-through: 13 Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b61ddcaf41cfd19bee8df7096fd8ca2029f89088 Modified Files -- src/backend/access/transam/commit_ts.c | 7 +++ 1 file changed, 7 insertions(+)
pgsql: Disable commit timestamps during bootstrap
Disable commit timestamps during bootstrap Attempting to use commit timestamps during bootstrapping leads to an assertion failure, that can be reached for example with an initdb -c that enables track_commit_timestamp. It makes little sense to register a commit timestamp for a BootstrapTransactionId, so let's disable the activation of the module in this case. This problem has been independently reported once by each author of this commit. Each author has proposed basically the same patch, relying on IsBootstrapProcessingMode() to skip the use of commit_ts during bootstrap. The test addition is a suggestion by me, and is applied down to v16. Author: Hayato Kuroda Author: Andy Fan Reviewed-by: Bertrand Drouvot Reviewed-by: Fujii Masao Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/oscpr01mb14966ff9e4c4145f37b937e52f5...@oscpr01mb14966.jpnprd01.prod.outlook.com Discussion: https://postgr.es/m/87plejmnpy@163.com Backpatch-through: 13 Branch -- REL_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/29a4b63c6bc83a7c21e3ccd0f484eee9a91be7d8 Modified Files -- src/backend/access/transam/commit_ts.c | 7 +++ src/test/modules/commit_ts/t/001_base.pl | 3 +-- 2 files changed, 8 insertions(+), 2 deletions(-)
pgsql: Disable commit timestamps during bootstrap
Disable commit timestamps during bootstrap Attempting to use commit timestamps during bootstrapping leads to an assertion failure, that can be reached for example with an initdb -c that enables track_commit_timestamp. It makes little sense to register a commit timestamp for a BootstrapTransactionId, so let's disable the activation of the module in this case. This problem has been independently reported once by each author of this commit. Each author has proposed basically the same patch, relying on IsBootstrapProcessingMode() to skip the use of commit_ts during bootstrap. The test addition is a suggestion by me, and is applied down to v16. Author: Hayato Kuroda Author: Andy Fan Reviewed-by: Bertrand Drouvot Reviewed-by: Fujii Masao Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/oscpr01mb14966ff9e4c4145f37b937e52f5...@oscpr01mb14966.jpnprd01.prod.outlook.com Discussion: https://postgr.es/m/87plejmnpy@163.com Backpatch-through: 13 Branch -- REL_16_STABLE Details --- https://git.postgresql.org/pg/commitdiff/7e7059abfd2296b8716d2648baea67c445492cce Modified Files -- src/backend/access/transam/commit_ts.c | 7 +++ src/test/modules/commit_ts/t/001_base.pl | 3 +-- 2 files changed, 8 insertions(+), 2 deletions(-)
pgsql: Disable commit timestamps during bootstrap
Disable commit timestamps during bootstrap Attempting to use commit timestamps during bootstrapping leads to an assertion failure, that can be reached for example with an initdb -c that enables track_commit_timestamp. It makes little sense to register a commit timestamp for a BootstrapTransactionId, so let's disable the activation of the module in this case. This problem has been independently reported once by each author of this commit. Each author has proposed basically the same patch, relying on IsBootstrapProcessingMode() to skip the use of commit_ts during bootstrap. The test addition is a suggestion by me, and is applied down to v16. Author: Hayato Kuroda Author: Andy Fan Reviewed-by: Bertrand Drouvot Reviewed-by: Fujii Masao Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/oscpr01mb14966ff9e4c4145f37b937e52f5...@oscpr01mb14966.jpnprd01.prod.outlook.com Discussion: https://postgr.es/m/87plejmnpy@163.com Backpatch-through: 13 Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/dcbbd43317c0c089c24952782a30f1717f6f99be Modified Files -- src/backend/access/transam/commit_ts.c | 7 +++ 1 file changed, 7 insertions(+)
pgsql: Disable commit timestamps during bootstrap
Disable commit timestamps during bootstrap Attempting to use commit timestamps during bootstrapping leads to an assertion failure, that can be reached for example with an initdb -c that enables track_commit_timestamp. It makes little sense to register a commit timestamp for a BootstrapTransactionId, so let's disable the activation of the module in this case. This problem has been independently reported once by each author of this commit. Each author has proposed basically the same patch, relying on IsBootstrapProcessingMode() to skip the use of commit_ts during bootstrap. The test addition is a suggestion by me, and is applied down to v16. Author: Hayato Kuroda Author: Andy Fan Reviewed-by: Bertrand Drouvot Reviewed-by: Fujii Masao Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/oscpr01mb14966ff9e4c4145f37b937e52f5...@oscpr01mb14966.jpnprd01.prod.outlook.com Discussion: https://postgr.es/m/87plejmnpy@163.com Backpatch-through: 13 Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8bca4476f9f9b364506f20973f9a36351010 Modified Files -- src/backend/access/transam/commit_ts.c | 7 +++ 1 file changed, 7 insertions(+)
