pgsql: Disable commit timestamps during bootstrap

2025-07-03 Thread Michael Paquier
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 BootstrapTransaction

pgsql: Disable commit timestamps during bootstrap

2025-07-03 Thread Michael Paquier
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 BootstrapTransaction

pgsql: Disable commit timestamps during bootstrap

2025-07-03 Thread Michael Paquier
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 BootstrapTransaction

pgsql: Disable commit timestamps during bootstrap

2025-07-03 Thread Michael Paquier
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 BootstrapTransaction

pgsql: Disable commit timestamps during bootstrap

2025-07-03 Thread Michael Paquier
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 BootstrapTransaction

pgsql: Disable commit timestamps during bootstrap

2025-07-03 Thread Michael Paquier
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 BootstrapTransaction

pgsql: Disable commit timestamps during bootstrap

2025-07-03 Thread Michael Paquier
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 BootstrapTransaction

pgsql: Speed up truncation of temporary relations.

2025-07-03 Thread Fujii Masao
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

pgsql: Simplify COALESCE() with one surviving argument.

2025-07-03 Thread Tom Lane
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 imp

pgsql: Add cross-type comparisons to contrib/btree_gin.

2025-07-03 Thread Tom Lane
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 u

pgsql: Break out xxx2yyy_opt_overflow APIs for more datetime conversion

2025-07-03 Thread Tom Lane
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

pgsql: Add more cross-type comparisons to contrib/btree_gin.

2025-07-03 Thread Tom Lane
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

pgsql: Obtain required table lock during cross-table updates, redux.

2025-07-03 Thread Tom Lane
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

pgsql: Obtain required table lock during cross-table updates, redux.

2025-07-03 Thread Tom Lane
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

pgsql: Obtain required table lock during cross-table updates, redux.

2025-07-03 Thread Tom Lane
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

pgsql: Obtain required table lock during cross-table updates, redux.

2025-07-03 Thread Tom Lane
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

pgsql: Obtain required table lock during cross-table updates, redux.

2025-07-03 Thread Tom Lane
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

pgsql: Obtain required table lock during cross-table updates, redux.

2025-07-03 Thread Tom Lane
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

pgsql: Obtain required table lock during cross-table updates, redux.

2025-07-03 Thread Tom Lane
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

pgsql: Add tab-completion for ALTER TABLE not-nulls

2025-07-03 Thread Álvaro Herrera
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. A

pgsql: Remove leftover dead code from commit_ts.h.

2025-07-03 Thread Fujii Masao
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 i

Re: pgsql: Fix bogus grammar for a CREATE CONSTRAINT TRIGGER error

2025-07-03 Thread Álvaro Herrera
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

pgsql: Fix broken XML

2025-07-03 Thread Álvaro Herrera
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/81a2625eb2e4608ba6ca41b2bf548d

pgsql: doc: Update outdated descriptions of wal_status in pg_replicatio

2025-07-03 Thread Fujii Masao
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

pgsql: doc: Update outdated descriptions of wal_status in pg_replicatio

2025-07-03 Thread Fujii Masao
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

pgsql: doc: Update outdated descriptions of wal_status in pg_replicatio

2025-07-03 Thread Fujii Masao
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

pgsql: doc: Update outdated descriptions of wal_status in pg_replicatio

2025-07-03 Thread Fujii Masao
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

Re: pgsql: Fix bogus grammar for a CREATE CONSTRAINT TRIGGER error

2025-07-03 Thread Daniel Gustafsson
> 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. +

pgsql: Prevent creation of duplicate not-null constraints for domains

2025-07-03 Thread Álvaro Herrera
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/CACJufx

pgsql: Prevent creation of duplicate not-null constraints for domains

2025-07-03 Thread Álvaro Herrera
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/CACJufx

pgsql: Fix bogus grammar for a CREATE CONSTRAINT TRIGGER error

2025-07-03 Thread Álvaro Herrera
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

pgsql: Refactor subtype field of AlterDomainStmt

2025-07-03 Thread Michael Paquier
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 characte

pgsql: doc: Remove incorrect note about wal_status in pg_replication_sl

2025-07-03 Thread Fujii Masao
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 t

pgsql: doc: Remove incorrect note about wal_status in pg_replication_sl

2025-07-03 Thread Fujii Masao
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 t

pgsql: doc: Remove incorrect note about wal_status in pg_replication_sl

2025-07-03 Thread Fujii Masao
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 t

pgsql: doc: Remove incorrect note about wal_status in pg_replication_sl

2025-07-03 Thread Fujii Masao
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 t

pgsql: doc: Remove incorrect note about wal_status in pg_replication_sl

2025-07-03 Thread Fujii Masao
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 t

pgsql: doc: Remove incorrect note about wal_status in pg_replication_sl

2025-07-03 Thread Fujii Masao
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 t

pgsql: doc: Remove incorrect note about wal_status in pg_replication_sl

2025-07-03 Thread Fujii Masao
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 t