pgsql-hackers Weekly Digest

This thread proposes a new `PAGEFAULTS` option for `EXPLAIN (ANALYZE)` to report minor and major page fault counts during query planning and execution. The goal is to provide deeper insights into storage I/O activity beyond what `BUFFERS` currently offers, aiding in diagnosing slow queries. Early discussions covered platform limitations (Windows `getrusage()`) and the performance impact of per-node reporting. A key ongoing concern is the accuracy of `getrusage()` with asynchronous I/O methods, particularly bgworker-based AIO, which could lead to undercounting. The proposer adapted the patch to suppress output when `io_method=worker`. Reviewers have provided detailed feedback on output format, naming, documentation, and test coverage, leading to iterative patch revisions. The thread is still active, with a reviewer recently reiterating concerns about the interpretability of the reported I/O statistics.

This thread discusses the proposal and implementation of a conflict log history table for PostgreSQL's Logical Replication feature. The proposer introduced a series of patches (up to v37) to create a system-managed `pg_conflict` schema and associated tables to record replication conflicts. Key discussion points include the design of the `ConflictLogDest` enum, handling of schema renaming for `pg_conflict` (comparing it to `pg_catalog`), and the management of internal dependencies for the conflict log tables. Reviewers provided detailed feedback on code structure, commit messages, documentation accuracy, and test cases. Specific suggestions were made regarding the naming and refactoring of dependency management functions, ordering of schema definitions, and clarification of documentation related to conflict logging behavior and JSON array descriptions. The broader implication of preserving subscription OID was also raised as a separate but related concern. The overall aim is to refine the implementation for robustness, clarity, and maintainability.

This thread discusses a patch to add `WHERE` clause support to `REFRESH MATERIALIZED VIEW`, enabling partial refreshes to improve performance by targeting only changed data. The proposer initially implemented a 'Prune + Upsert' strategy for non-concurrent refreshes. An early commenter highlighted a real-world need for this feature. Reviewers identified a bug in unique index handling and raised concerns about consistency gaps in the non-concurrent mode. The proposer considered using transaction-level advisory locks to address concurrency but abandoned it due to scalability issues. The revised approach for non-concurrent refreshes now uses `SELECT ... FOR UPDATE` followed by a single CTE for upsert/delete. Discussion also touched upon whether the `CONCURRENTLY` keyword's semantics might become inverted with a `WHERE` clause, and the need for clear documentation on concurrency guarantees for this feature.

The proposer reported a bug where SQL-callable replication slot functions (like pg_replication_slot_advance) can fail to release an acquired replication slot if an error occurs and is caught by a PL/pgSQL EXCEPTION block. This leads to a stale MyReplicationSlot process-global variable, causing an Assert crash in debug builds or silently orphaning the slot in release builds. Orphaned slots prevent other sessions from acquiring them and block vacuum and WAL deletion. The proposer provided a patch using PG_TRY/PG_CATCH blocks to ensure ReplicationSlotRelease() is called on error. Reviewers confirmed the approach, but raised questions about handling temporary logical replication slots which ReplicationSlotRelease() might not fully drop, and identified other functions (pg_copy_logical_replication_slot(), pg_logical_slot_get_changes()) that might suffer from similar issues, requiring a broader fix.

The thread begins with the proposer reporting a bug where `pg_stat_wal_receiver` does not show the `CONNECTING` status for a WAL receiver, which contradicts the original intent for monitoring. The proposer suggests a patch (v1) to display a minimal row with the PID and 'connecting' status when `WalRcv->ready_to_display` is false. A reviewer proposes an alternative patch (v2) that refines how `WalRcv->ready_to_display` is used, splitting the data filling into two steps to ensure `CONNECTING` status is visible without exposing potentially stale connection details. The proposer initially raises concerns about v2's display of `last_msg_send_time` and `last_msg_receipt_time` during the `CONNECTING` state, arguing they could be misleading if showing initial timestamp values rather than actual message activity. The reviewer defends v2, explaining that these values reflect the initialized state of the WAL receiver and can still be useful. The proposer eventually accepts v2, suggesting a documentation update for clarity. However, the proposer then discovers a new, related bug: a `conninfo` leak in the WAL receiver reuse path, where old connection information could persist while in `CONNECTING` or `WAITING` states. The proposer describes the leak and proposes a new patch to address it by only copying primary connection info when switching to `WALRCV_STARTING`, avoiding unnecessary `conninfo` clobbering. The reviewer confirms this new bug is legitimate, affects stable branches, and requests the proposer to submit the patch for backporting.

The proposer suggests changing PostgreSQL's major versioning scheme from a sequential integer (e.g., Postgres 19) to a year-based one (e.g., Postgres 26 for 2026). The primary motivation is to make it easier for users to quickly determine the age of a running PostgreSQL instance, as the project has a stable annual release cycle. The proposer believes aligning the version number with the last two digits of the release year would improve memorability and provide better context for users managing multiple database versions. A commenter supports the idea, noting similar versioning approaches in other operating systems (macOS) and distributions (Ubuntu, Debian), and suggests the possibility of also naming releases.

The proposer identified an information leakage bug in the pg_available_extensions view. When the extension_control_path parameter is explicitly set to an empty string, the location column incorrectly displays the absolute system path (e.g., /usr/local/pgsql/share/extension) instead of the documented '$system'. This behavior contradicts the documentation, which states that an empty string for this parameter should default to '$system'. The proposer provided a straightforward patch to correct this, ensuring that '$system' is displayed as expected in this scenario. Multiple reviewers reproduced the bug and confirmed the patch fixes the issue.

This extensive thread focuses on optimizing `LISTEN/NOTIFY` functionality. The proposer introduced a new design for tracking `LISTEN` state using hash tables at three levels: per-transaction pending changes, per-backend committed state cache, and cluster-wide shared state. This aimed to reduce shared dshash operations by performing more work locally and deduplicating actions. Significant discussion revolved around the terminology and the handling of 'laggard' backends not interested in specific notifications, to avoid a 'thundering herd' problem. A reviewer proposed a revised patch (v35) incorporating cosmetic changes and bug fixes, including restoring the previous behavior for laggard backends. The latest messages indicate that v35 was committed, and a follow-up comment identified an inconsistency in the `async-notify.spec` test related to `ChannelHashAddListener()`, which was eliminated in an earlier patch version.

The proposer initiated a thread to add `amcheck` support for BRIN indexes, outlining a patch with index structure checks (meta page, revmap, regular pages) and consistency checks between heap and index. Early discussions revolved around how to handle operator identification for the 'all consistent check', especially for opclasses that lack an equality operator, with commenter 1 suggesting leveraging existing primitives and the proposer exploring user-defined operators or a catalog mapping. Reviewer 1 provided detailed feedback, proposing an optional operator argument, requiring tests for multi-column indexes, suggesting improvements to the `CheckIndexCheckXMin` function, and requesting documentation updates. The proposer subsequently updated the patch to incorporate some of these suggestions, making the operator list optional and relocating `indcheckxmin`. More recently, the proposer reiterated the idea of an opclass-to-operator mapping to simplify user experience. Reviewer 2 successfully applied and built the updated patch, performing basic validation tests and noting a necessary `ALTER EXTENSION amcheck UPDATE` for existing `amcheck` installations, which the proposer confirmed as expected behavior for upgrades.

This thread proposes a new feature, `pg_stat_io_histogram`, to track and display I/O latency profiles, aiming to help users identify I/O outliers quickly. The initial patch focused on avoiding overhead with fast bucket calculation. Much of the subsequent discussion revolved around optimizing memory usage, particularly in each backend and in shared memory, as early versions significantly increased `pgStatLocal` and `PendingIOStats` sizes. Reviewers raised concerns about wasting memory for unused statistics. The proposer developed several patch versions (v7, v9a, v9b, v10) exploring different memory optimization strategies, including dynamically allocating memory and using indirect offsets to reduce the footprint. Performance testing indicated negligible CPU impact. The debate also included histogram range and bucket width. The latest patch, v10, aims to address memory concerns using indirect offsets and dynamic shared memory allocation on startup, making the shared memory footprint acceptable.

This thread proposes a mechanism to bypass cursors in `postgres_fdw` to enable parallel query plans on the remote server, addressing a limitation where parallel plans fail due to cursor usage. The initial approach introduced a GUC `postgres_fdw.use_cursor` and used `PQsetChunkedRowsMode` in non-cursor mode. A challenge arose with simultaneous queries, leading to the development of a mechanism to store fetched data in a Tuplestore when a cursor switch occurs. The patch underwent significant refactoring based on reviewer feedback, including adding a Tuplestore to `PgFdwScanState`, renaming flags, and improving `postgresReScanForeignScan` logic. Discussions highlighted issues like unnecessary code, flag naming, `active_scan` pointer management, and `ExprContext` usage. The latest version of the patch split the changes into two, the first renaming `cursor_exists` to `scan_in_progress` and the second implementing the fetch mechanism, and introduced a new GUC `streaming_fetch`.

The proposer identified an issue where NOTICE messages generated during libpq connection establishment, such as from login triggers, are not correctly logged via ereport() but are instead printed to stderr. This occurs because the libpqsrv_notice_receiver is installed too late in the connection process. The proposer initially suggested adding wrapper functions to install the receiver earlier. A reviewer, however, proposed a more general solution: splitting the libpqsrv_connect() function into two phases, libpqsrv_connect_start() and libpqsrv_connect_complete(), to allow the notice receiver to be set in the interim. The proposer agreed to this refactoring approach.

The proposer identified a bug in `pg_upgrade` when upgrading from PostgreSQL 17 to a newer version. The issue occurs when a user explicitly defines a `NOT NULL` constraint using `CHECK ((i is not null)) NOT VALID`, which `pg_restore` fails to re-add because an implicitly created `NOT NULL` constraint with the same name already exists. This leads to an "ERROR: constraint already exists". The proposer suggested a fix involving choosing a less obvious, unique name for `NOT NULL` constraints generated during `CREATE TABLE` processing to avoid naming conflicts. They also noted this change might affect non-`pg_upgrade` operations and offered to prepare a patch.

This thread proposes an enhancement to psql's `\dRp+` command, aiming to prevent it from listing individual tables if they are already encompassed by a `FOR TABLES IN SCHEMA` clause within a publication. The proposer argued that the current behavior creates confusing output, especially when row filters or future `EXCEPT` clauses are involved. Commenters supported the idea, leading to the incorporation of a similar logic to improve the `\d+` command, ensuring tables are not redundantly displayed. A discussion on including a PostgreSQL 15 version check for catalog access in psql was resolved by adding it as a precautionary measure. The patch has undergone several revisions and is now considered complete and ready for a committer's review.

The thread addresses a race condition in the async notification mechanism (`async.c`) that can cause `LISTEN` clients to entirely miss `NOTIFY` messages. This occurs when a `NOTIFY` commits in a brief window between a listener registering its queue position and becoming active. During this window, `SignalBackends()` might incorrectly conclude the listener isn't interested and advance its queue pointer past the notification, leading to a "false negative" where a notification is lost. The proposer suggested a fix that involves treating staged `LISTEN` entries as potential listeners when deciding whom to wake. The proposed solution includes three patches: two tests and the fix. A reviewer confirmed the bug and the effectiveness of the fix, also pointing out a test file duplication and another related scenario addressed by the patch.

This thread proposes adding a new flag, initially `--pipe-command` and later renamed to `--pip`, to `pg_dump` and `pg_restore` for use with the directory output format (`-Fd`). The feature aims to enable piping individual dump files to external commands, offering flexibility for custom compression, streaming to cloud storage, or transferring data via SSH, which is currently not possible with the directory format. The proposer introduced a `%f` specifier for dynamic file naming within the pipe command. A reviewer provided extensive feedback, suggesting a shorter flag name, improved error handling, more comprehensive testing, and considering `pg_dumpall` support. The proposer has since rebased the patch multiple times, incorporated many suggestions including renaming the flag to `--pip`, enhancing error handling, adding numerous tests for various scenarios and parallelism, and specifically addressing Windows compatibility. Support for `pg_dumpall` has been deferred for a future patch.

The proposer identified a bound-overlap bug in ALTER TABLE ... SPLIT PARTITION and other areas needing improvement, including unclear documentation for splitting with a DEFAULT partition and a need for better error messages. The initial proposal included multiple patches, with a reviewer confirming that patches 0001-0003 were ready. The proposer then identified a collation-related issue in patch 0004 concerning LIST partitions and provided a revised version. The reviewer subsequently committed patches 0001-0003 and revised patch 0004, adding further tests. The discussion continued around the details of patch 0004, focusing on correct handling of collations and ensuring proper bound comparisons for LIST partitions.

The thread discusses an inconsistency in PostgreSQL's `synchronized_standby_slots` where it requires all listed slots to catch up, even when `synchronous_standby_names` is configured for quorum (ANY M of N) replication. This leads to logical decoding blocking if a non-essential standby goes down. The proposer introduced a patch to extend `synchronized_standby_slots` with quorum-aware syntax (ANY M of N) and later proposed adding priority-based syntax (FIRST N). The discussion evolved to splitting the work into three patches: first, refactoring the synchronous replication parser to better distinguish syntax forms; second, implementing `ANY N` semantics; and third, implementing `FIRST N` semantics. Reviewers provided feedback, including identifying a bug where duplicate entries in priority configuration are not filtered, which the proposer has committed to addressing.

This thread discusses improvements and bug fixes related to the `WAIT FOR LSN` functionality, particularly concerning how replay waiters are woken up and memory barrier semantics. Initial patches addressed a misplaced wake-up call and memory barriers in `GetWalRcvWriteRecPtr()`. The discussion involved ensuring proper handling of `writtenUpto` with atomic operations and robust testing for various scenarios, including off-by-one errors and timeline boundaries. The proposer assembled a patchset, which underwent several revisions to incorporate feedback, improve test coverage, and address a newly discovered test failure in `wait_for_catchup()`. The thread concludes with the proposer reviewing a fix for this test failure and the initial patchset being committed.

This thread proposes and reviews a new function, `pg_get_publication_ddl`, designed to generate the DDL for PostgreSQL publication objects. The proposer initially submitted a patch (v1) and sought feedback, particularly on the implications of viewing publication details without explicit 'view' privileges and how to handle default values. Reviewers provided extensive feedback on v1, pointing out numerous typos, potential information leaks due to missing `ONLY` clauses, incorrect schema prefix handling, and suggesting various code and documentation improvements. The proposer then submitted v2, incorporating a new structure, adding `pretty` and `owner` options, improving string management, using cache instead of shared locks, addressing grammar, and enhancing test coverage, including support for the `EXCEPT` clause. Reviewers are now actively providing detailed feedback on the v2 patch, focusing on documentation clarity, parameter naming, and minor code style adjustments to further refine the proposal.

This thread discusses a bug where the deadlock detection mechanism fails to activate on a hot standby replica, specifically when a deadlock occurs between startup and backend processes during XLOG_HEAP2_PRUNE_* message processing. This can lead to significant recovery delays, especially if `max_standby_streaming_delay` is disabled. The proposer identified that the root cause lies in `timeout.c` and `ResolveRecoveryConflictWithBufferPin`, where the `SIGALRM` handler can be triggered "spontaneously" due to an optimization in `setitimer` calls, prematurely waking up the process before an actual timeout. If `deadlock_timeout` is larger than `log_startup_progress_interval`, the deadlock detector may never trigger. The proposer submitted a patch aimed at ignoring these spontaneous `SIGALRM` signals. A reviewer then provided detailed feedback on the patch, suggesting improvements to include ordering, clarifying comments regarding `ProcWaitForSignal` wake-ups, explicitly checking the waiter state, and simplifying the control flow within the waiting loop.

This thread proposes a patch to correct documentation inaccuracies related to the bind message protocol. The proposer identifies that the documentation incorrectly describes the counts for parameter format codes, parameter values, and result-column format codes as signed integers, when they are actually unsigned integers according to the source code. The patch aims to update the documentation to reflect this correction.

The proposer initiated a discussion on improving the scalability of pg_stat_statements, highlighting three primary issues: high spinlock contention, performance bottlenecks during hash table deallocation under exclusive locks, and query text file bloat with inefficient garbage collection. The proposed solution leverages the existing PostgreSQL statistics collector (pgstat) system, which offers local stat writing, periodic flushing to shared memory, and dynamic resizing capabilities. The work builds on recent PostgreSQL developments in pluggable cumulative statistics and serialization callbacks. The proposer later reorganized the patches and fixed an issue causing CI failures related to parallel query execution, providing an updated series.

This thread addresses a bug where a REPACK decoding worker process and its temporary replication slot were not properly cleaned up when the main REPACK session terminated via a `FATAL` exit (e.g., `pg_terminate_backend`). The initial proposer identified that `FATAL` exits bypass `PG_FINALLY` blocks, preventing the worker's cleanup function from being called. The proposer's first patch used `on_proc_exit` callbacks, but reviewer 1 found it caused a segfault due to use-after-free, suggesting `before_shmem_exit` instead. Committer 1 then proposed `PG_ENSURE_ERROR_CLEANUP()` as the most robust solution, which handles both `ERROR` and `FATAL` exits, automatically cancels on normal completion to prevent slot leaks, and runs before memory contexts are destroyed. The proposer's v3 patch implemented this, successfully resolving the issues and passing tests. Committer 1 subsequently pushed the fix, along with further refinements to `stop_repack_decoding_worker()` to improve memory handling. Commenter 1 then inquired about a potential omission of `shm_mq_detach()`, leading to a brief discussion about automatic detachment of shared memory queues.

The proposer has initiated a feature request for native nanosecond precision support within PostgreSQL's temporal data types (timestamp, timestamptz, time). They argue that this capability is increasingly critical for modern analytical and financial systems, which often process data requiring nanosecond resolution. The proposer cites several widely used data formats and databases that already support this precision, including Parquet, DuckDB, ClickHouse, Oracle, SAS, Pandas, and NumPy. Currently, PostgreSQL users resort to workarounds such as auxiliary nanosecond-remainder columns, bigint epoch encodings, or custom extensions. The proposer contends that native support would bring consistent casting and operator semantics, improve integration with drivers, ORMs, and FDWs, and establish a standardized approach, thereby making PostgreSQL more competitive for workloads involving high-resolution datasets like market microstructure research.

A bug was reported where `pg_dump --statistics-only` fails with an "could not find index attname" error when a table has multiple indexes, including an index on an expression. The proposer provided a simple patch, explaining that `pg_dump` can incorrectly use attribute names from a previously processed index on an expression for a subsequent regular index. A reviewer confirmed the underlying bug (incorrect inheritance of `indAttNames`), but couldn't reproduce the user-facing error on a vanilla PostgreSQL system. The proposer's latest reply clarified that the issue arises in their specific fork because it generates `pg_statistics` entries for all indexes, unlike vanilla PostgreSQL which only does so for expression indexes. This explains why the bug is not easily reproducible on vanilla, but the underlying issue of `pg_dump` misusing `indAttNames` after processing an expression index remains pertinent to the patch.

The proposer initiated a thread announcing OpenSSL 4.0.0 release and the need to adapt PostgreSQL. The initial patch addressed compilation warnings arising from const changes in OpenSSL 4.0.0 APIs, ensuring libpq and sslinfo build without warnings across OpenSSL 1.1.1 to 4.0.0 and LibreSSL. Commenter 1 inquired about back-patching and compatibility with older OpenSSL versions. The proposer confirmed the need for back-patching and discussed the implications for older PostgreSQL branches (v14-master), initially suggesting to limit back-patching on v14 due to its older OpenSSL support. Commenter 2 tested the patch and found an issue with SSL tests failing due to OpenSSL 4.0 changing "ssl alert" to "tls alert" in error messages, which the proposer indicated might have been fixed in a later patchset. A core developer then weighed in, recommending back-patching to all branches, including v14, after the next minor releases, given that v14 still has two scheduled releases, allowing time to address any potential issues. The proposer accepted this plan and committed to preparing rebased patches for all branches.

The proposer has submitted a patch set introducing multi-entry indexing for GiST and SP-GiST access methods. This new functionality enables a single heap tuple to generate multiple index entries, akin to GIN's `extractValue`. The primary motivation is to enhance the precision of operators like `@>` and `<@` for composite data types such as multiranges, especially those with gaps, which currently suffer from numerous false positives. Additionally, it provides the first multirange opclass support for SP-GiST. The design integrates an optional `extractValue` support function (proc 13 for GiST, proc 8 for SP-GiST) that decomposes a datum into sub-entries during index insertion and building. During scans, a TID hash ensures result deduplication, and for KNN scans, an early filter is applied. The proposer also outlines semantic considerations for opclass authors, noting that consistent functions will process one sub-entry at a time, often necessitating `recheck=true` for accuracy.

The proposer identified a bug where `NOT NULL` constraints on partitioned tables could be configured with `NO INHERIT` using `ALTER CONSTRAINT`, despite being disallowed during initial table creation. This inconsistency is deemed an oversight. To address this, a patch has been provided which introduces a check to prevent `ALTER TABLE ... ALTER CONSTRAINT ... NO INHERIT` on `NOT NULL` constraints for partitioned tables, ensuring that such operations are consistently rejected across both `CREATE TABLE` and `ALTER TABLE` statements. The proposer included SQL examples demonstrating the problematic behavior.

The proposer identified a critical use-after-free bug within the `ri_triggers.c` module, specifically in `RI_FKey_cascade_del`. This vulnerability can lead to a segmentation fault when a DELETE operation is performed on a self-referential table that has `BEFORE DELETE` triggers which also delete rows from the same table. The issue arises during reentrant RI trigger execution if the plancache is invalidated, causing a freed Postgres plan to be used prematurely. To address this, the proposer submitted two patches: one introducing a test case to reliably reproduce the segmentation fault, and another implementing reentrancy guards in `ri_triggers.c`. These guards are designed to maintain a reference count for plans currently in execution, thereby preventing their premature deallocation.

The thread discusses a patch to enable function scan pushdown for Foreign Data Wrappers (FDW), specifically for PostgreSQL FDW. The initial patch was returned with feedback due to unresolved issues with `rte->functions` and an unfinished design. The proposer submitted an updated patch (v3), disallowing pushdown for functions returning complex types or with parameters. A reviewer tested v3 and v4, noting that pushdown was not observed in their tests due to planner cost estimation favoring local joins. The proposer explained the cost model, emphasizing that remote joins must be cheaper. Subsequent patch versions (v5, v6) addressed issues with deparsing whole-row variables for function RTEs and handling `postgresBeginForeignScan` for function RTEs. The discussion also involved restoring per-function metadata. The latest discussions focus on refining whole-row variable deparsing for nullable outer sides and correctly handling `fdw_private` data for base restrict infos, suggesting further complexity in the patch.

This thread proposes removing an obsolete test case related to the `LISTEN` array growth isolation. The test was identified as a leftover from a previous patch version for the `LISTEN/NOTIFY` optimization. The proposer indicated that a patch to remove this test would be submitted in a separate thread.

This thread discusses a patch aimed at preventing repeated `RECOVERY_CONFLICT_BUFFERPIN_DEADLOCK` signals during standby buffer pin waits. The proposer observed that when `deadlock_timeout` fires in `ResolveRecoveryConflictWithBufferPin()`, the function repeatedly sends the deadlock-check signal without waiting, similar to a previously fixed issue in the lock-conflict path. The proposed solution involves resetting the `got_standby_deadlock_timeout` flag and calling `ProcWaitForSignal()` after the signal, allowing the startup process to wait for `UnpinBuffer()` instead of looping. Reviewer 1 and reviewer 2 generally approved the patch, classifying it as an improvement rather than a bug fix, suggesting it target the v20 release. Reviewer 1 also suggested a minor initialization for symmetry, which the proposer incorporated into a v2 patch, confirming its performance benefit by reducing signal broadcasts during testing. However, a commenter later questioned the classification as an 'improvement,' citing another report where a similar issue was considered a bug dating back to an earlier PostgreSQL version.

This thread addresses a bug in `pg_recvlogical` where it failed to preserve group permissions on its output files, despite documentation stating otherwise. The issue stemmed from output files being created with a hard-coded mode rather than respecting the source cluster's group permissions. The proposer submitted a patch to use `pg_file_create_mode` and update the documentation. A reviewer provided a TAP test to verify the fix. The proposer then refined the TAP test to cover both scenarios: when group access is enabled and when it's disabled, ensuring `pg_recvlogical` correctly applies permissions (0640 vs 0600). The patch, including the improved test (for master branch), has been committed.

The proposer introduced a new feature proposal to add a `COPY <t> TO BLACKHOLE` command and a `pg_dump -Fb` format. The motivation stems from current inefficiencies in corruption checking using `COPY to /dev/null` or `verify_heapam()`, and the large disk space requirement for parallel `pg_dump -j` operations that demand a directory format. The `BLACKHOLE` target would discard data, providing a performance optimization over writing to `/dev/null` (benchmarked at 11-14% faster). The `pg_dump -Fb` option would allow parallel dumping without generating output files, thus saving significant disk space on large installations. The proposer is seeking community feedback on the usefulness of these changes.

This thread addresses a critical false-negative conflict detection issue in logical replication. The problem arises when a `ReplOriginId` is reused after a subscription is dropped, causing a new subscription to incorrectly identify previously replicated changes as its own, thereby skipping conflict detection. The proposer introduced two approaches: 1) nullifying old origin IDs in `commit_ts` data on subscription drop, which is comprehensive but potentially expensive and not crash-safe without WAL logging; and 2) adding a creation timestamp to each replication origin and comparing it during conflict checks, deemed lightweight and crash-safe. Reviewers confirmed the problem's significance. A separate scenario involving publisher switching was clarified as outside the current replication model's scope. While LSN matching was considered as an alternative to timestamps, it would necessitate extending the `commit_ts` structure, making Approach 2 (timestamps) the more practical option currently under consideration.

The proposer identified a bug in the `statext_dependencies_deserialize()` function where an incorrect size validation check was being performed. Specifically, `SizeOfItem` was mistakenly used instead of `MinSizeOfItems`, leading to an erroneous calculation of the expected bytea size. The proposer noted that a similar function for ndistinct extended statistics correctly uses `MinSizeOfItems`, suggesting the issue was a typo. A reviewer confirmed the validity of the bug report, praised the discovery, and indicated that they would fix the issue.

The proposer identified a bug in pg_rewind where a rewound standby node can take an unacceptably long time to reach a consistent state if the new primary is idle. This occurs because pg_rewind sets the minRecoveryPoint using pg_current_wal_insert_lsn(), which can point just past a WAL page header when the primary is idle. Consequently, the standby waits indefinitely for a new WAL record to be written by the primary to advance its lastReplayedEndRecPtr past this minRecoveryPoint. The proposer suggested using GetXLogInsertEndRecPtr() instead, or adjusting the minRecoveryPoint if it's just after a WAL page header. A reviewer reproduced the bug and confirmed the diagnosis, agreeing that fixing the producer (pg_rewind) by using GetXLogInsertEndRecPtr() is the cleaner solution to maintain consistency across how minRecoveryPoint is set and compared. The reviewer also suggested additional documentation and auditing for a defense-in-depth approach, and offered to provide a TAP test, emphasizing the liveness bug's importance for back-patching.

A proposer introduced a new contrib module, `anyarray`, aiming to generalize `contrib/intarray` functionality for any array type with a default btree opclass. The initial submission contained the patch embedded in the email body, which commenter 1 noted, requesting a proper attachment.

The proposer announced the imminent shutdown of Cirrus CI on June 1, 2026, which is used by cfbot and individual developers, necessitating an urgent replacement. The proposer outlined seven key considerations for a new CI system, including self-hosting, open-source nature, speed, multi-OS support, personal repository integration, and free access. Commenters largely agreed on the importance of enabling CI on personal repositories and the desirability of self-hosting and open-source solutions. There was also discussion about optimizing CI resource usage, particularly for small or inactive patches, while preserving the value of initial runs. Towards the deadline, one developer provided an initial GitHub Actions YAML file as a temporary solution to ensure CI continuity, acknowledging it's not the long-term goal. Another developer then offered to take over and refine this patch.

The proposer reported and provided detailed reproduction steps for a known bug where VACUUM FULL or CREATE INDEX can fail with "ERROR: missing chunk number 0 for toast value". The bug stems from a discrepancy in transaction horizon computation between a main table's VACUUM and its associated TOAST table's VACUUM. Specifically, ComputeXidHorizons for the main table respects local database transactions, preventing old tuples from being immediately removed. However, when the TOAST table is vacuumed later, an external transaction holding up the main table's horizon might have committed. With no other active processes in the same database, the TOAST VACUUM can wrongly determine an OldestXmin that allows the TOAST tuples to be removed. Subsequently, a CREATE INDEX on the main table, calculating its own OldestXmin (which now considers the external transaction), expects the RECENTLY_DEAD main table tuple's TOAST value to exist but finds it missing. The proposer developed a prototype patch that reuses the parent table's OldestXmin when vacuuming a TOAST table to ensure consistent horizons.

This thread discusses an improvement to PostgreSQL's statistics system, aiming to address inaccuracies in statistics after a crash recovery or failover. The core proposal is to key statistics by `relfilenode` instead of relation OID, which can change. Earlier ideas, such as storing OID to buffertag mapping, were dismissed due to recovery limitations. The main debate focuses on the design of the `PgStat_StatTabEntry` structure. Reviewer 1 suggested splitting it into table, index, and relfilenode specific fields from the outset to avoid complexity, particularly concerning partitioned tables and unnecessary data for autovacuum. The proposer, supported by reviewer 2, argues for an incremental approach, advocating for a unified structure initially and considering a split later, once WAL-replay-based stat population is implemented. The proposer believes the current patch (v16) adequately addresses technical concerns and is a necessary step that doesn't hinder future architectural changes, and is seeking a committer to drive it forward.

This thread discusses the implementation of 'REPACK CONCURRENTLY', particularly focusing on the use of database-specific snapshots within the logical decoding mechanism. Initial concerns were raised about a plugin's declaration of not using shared catalogs, which led to a broader discussion about potential indirect breakages. The proposer identified a critical issue where the snapshot builder's transaction processing could incorrectly consider committed transactions as running when using database-specific snapshots, leading to lost data effects. A reviewer provided a clear method to reproduce this WAL ordering problem. Further architectural concerns were raised by another commenter regarding the fundamental mismatch between database-specific snapshots and the cluster-wide design of logical decoding, citing inefficiencies and limitations, such as incompatibility with standby servers. Due to these significant architectural challenges and the limited time before beta 1, a core developer decided to revert the database-specific snapshot aspect of 'REPACK CONCURRENTLY' for the current release (PostgreSQL 19), with the intention to revisit and redesign the feature for a future release (PostgreSQL 20).

This thread originated from the proposer identifying a typo in `src/include/port/atomics/arch-x86.h` (`__i568__`, `__i668__` instead of `__i586__`, `__i686__`). Initial discussions questioned whether to fix the typo or remove the code entirely, given its long-standing presence without issues. Investigation revealed inconsistent compiler behavior for 32-bit builds across different Linux distributions regarding these macros. Ultimately, the consensus shifted away from fixing the typo to removing the problematic 32-bit specific code altogether, as performance work for 32-bit builds was deemed a low priority. The committer agreed to apply the removal patch, with a separate fix for 64-bit MSVC detection to be addressed later.

This thread centers on a review of a patch introducing partial refreshes for materialized views using a WHERE clause. The reviewer raised several concerns regarding the patch's concurrency semantics. Key issues included potential deadlock scenarios arising from the proposed FOR UPDATE + single-CTE approach, particularly in cases of UPSERT conflicts. The reviewer also noted that the CONCURRENTLY behavior for WHERE refreshes appeared counter-intuitive, seemingly making the non-concurrent path more permissive for writers, which deviates from established REFRESH MATERIALIZED VIEW semantics. Documentation for intended guarantees around overlapping partial refreshes and concurrent DML on base tables was also suggested. Despite the valuable use case identified for high-churn refresh workloads, the subsequent messages in the thread did not address these technical points, instead focusing on administrative guidance for the reviewer regarding proper mailing list etiquette, specifically how to reply-all to the original thread.

This thread addresses an assertion failure encountered when using LATERAL GRAPH_TABLE with patterns matching multiple path queries. The proposer identified the bug, occurring in create_lateral_join_info when GRAPH_TABLE is used with UNION ALL for multi-label patterns, leading to !bms_is_member(rti, lateral_relids) assertion. The root cause was traced to rewriteGraphTable() bumping outer Vars for the initial subquery, but generate_setop_from_pathqueries() failing to bump Vars again when wrapping each path query in further subquery RTEs for the UNION ALL operation. This caused the lateral reference to incorrectly collapse onto the GRAPH_TABLE's own RTE. The proposed fix involves incrementing the sublevels_up for Vars within each lquery before it's wrapped in an RTE_SUBQUERY. A reviewer provided feedback on code comments, requested a clearer explanation of the connection between varlevelsup, subquery RTE addition, and the assertion failure, and suggested refining the provided test cases.

This thread discusses the implementation of Sequence Access Methods in PostgreSQL, allowing custom sequence generation. The proposer introduced several patch versions, with v11 being the first in the visible messages and v28/v29 later. A reviewer provided detailed feedback on v26, covering documentation clarity, header file ordering, handling of unlogged sequences, use of default constants, and macro design, to which the proposer largely responded. Another reviewer later rebased the patch set, offering comments on a snowflake sequence implementation and performance concerns related to function pointers. The proposer noted a lack of wider developer enthusiasm, leading to the patch being dropped from the commitfest, though he still supports the design. The latest exchanges include the second reviewer providing benchmark results for v29, indicating a slight performance improvement over the baseline, and suggestions for further optimization regarding cache lookups. The core idea is to enable extensible sequence generation, which is seen as crucial for distributed applications.

This thread proposes to extend the `EXCEPT` clause functionality to `TABLES IN SCHEMA` publications, similar to its existing use with `FOR ALL TABLES`. The goal is to provide users with a convenient way to exclude specific tables from schema-level publications without resorting to explicit `FOR TABLE` lists, which require manual updates. The proposer outlined a syntax for `CREATE`, `ALTER ADD`, and `ALTER SET` publication commands. Key rules include schema-qualification for excluded tables and ensuring they belong to the published schema. Early discussions focused on the syntax, particularly regarding 'mixed style' `EXCEPT` clauses (applying to multiple schemas in a single command). The proposer initially allowed this for convenience but later revised the approach to restrict `EXCEPT` to its adjacent schema clause to reduce complexity and confusion. The proposed changes are delivered in a series of three patches addressing different command types and related cleanup. Reviewers have provided detailed feedback on documentation, code logic, error messages, and `pg_dump` integration, to which the proposer has been responsive, providing updated patch versions.

This thread addresses a critical bug in the `COPY FROM ON_ERROR SET_NULL` command. The proposer identified that when a partial column list was used, particularly targeting higher-numbered columns, the system would incorrectly handle `NOT NULL` constraints on domain types. This led to an out-of-bounds read in `copyfromparse.c`, silently inserting `NULL` values into columns that should have enforced a `NOT NULL` constraint. The proposed solution involved correctly allocating the `domain_with_constraint[]` array using `num_phys_attrs` and indexing it with `attnum - 1`, ensuring consistency with other per-column arrays and proper constraint checking. A new test case was also included to cover the specific scenario. The fix was reviewed positively by multiple participants, with one reviewer noting they had independently found the same bug and developed a similar fix. The patch was subsequently committed.

The proposer identified a bug where `ALTER TABLE ... ALTER COLUMN ... SET EXPRESSION` failed to rebuild `CHECK` constraints that referenced a generated column using a whole-row `Var`, potentially leaving the table in an inconsistent state. The proposer's initial patch aimed to rebuild all `CHECK` constraints. Commenter 1 then expanded the scope to include whole-row references in indexes and RLS policies, demonstrating a more comprehensive solution across several patch versions. Discussion revolved around the detailed implementation, appropriate error messages, and whether to disallow `SET EXPRESSION` for whole-row policy references. Through several iterations, the patch was refined to correctly revalidate `CHECK` constraints and rebuild indexes, while safely ignoring whole-row policy references for `SET EXPRESSION` as they do not require action. The latest review confirmed the patch's effectiveness and correct behavior.

The proposer suggests changing PostgreSQL's major versioning scheme from a sequential integer (e.g., Postgres 19) to a year-based one (e.g., Postgres 26 for 2026). The primary motivation is to make it easier for users to quickly determine the age of a running PostgreSQL instance, as the project has a stable annual release cycle. The proposer believes aligning the version number with the last two digits of the release year would improve memorability and provide better context for users managing multiple database versions. A commenter supports the idea, noting similar versioning approaches in other operating systems (macOS) and distributions (Ubuntu, Debian), and suggests the possibility of also naming releases.

The proposer identified a bug in `pg_upgrade` when upgrading from PostgreSQL 17 to a newer version. The issue occurs when a user explicitly defines a `NOT NULL` constraint using `CHECK ((i is not null)) NOT VALID`, which `pg_restore` fails to re-add because an implicitly created `NOT NULL` constraint with the same name already exists. This leads to an "ERROR: constraint already exists". The proposer suggested a fix involving choosing a less obvious, unique name for `NOT NULL` constraints generated during `CREATE TABLE` processing to avoid naming conflicts. They also noted this change might affect non-`pg_upgrade` operations and offered to prepare a patch.

This thread proposes a patch to correct documentation inaccuracies related to the bind message protocol. The proposer identifies that the documentation incorrectly describes the counts for parameter format codes, parameter values, and result-column format codes as signed integers, when they are actually unsigned integers according to the source code. The patch aims to update the documentation to reflect this correction.

The proposer has initiated a feature request for native nanosecond precision support within PostgreSQL's temporal data types (timestamp, timestamptz, time). They argue that this capability is increasingly critical for modern analytical and financial systems, which often process data requiring nanosecond resolution. The proposer cites several widely used data formats and databases that already support this precision, including Parquet, DuckDB, ClickHouse, Oracle, SAS, Pandas, and NumPy. Currently, PostgreSQL users resort to workarounds such as auxiliary nanosecond-remainder columns, bigint epoch encodings, or custom extensions. The proposer contends that native support would bring consistent casting and operator semantics, improve integration with drivers, ORMs, and FDWs, and establish a standardized approach, thereby making PostgreSQL more competitive for workloads involving high-resolution datasets like market microstructure research.

The proposer identified a bug where `NOT NULL` constraints on partitioned tables could be configured with `NO INHERIT` using `ALTER CONSTRAINT`, despite being disallowed during initial table creation. This inconsistency is deemed an oversight. To address this, a patch has been provided which introduces a check to prevent `ALTER TABLE ... ALTER CONSTRAINT ... NO INHERIT` on `NOT NULL` constraints for partitioned tables, ensuring that such operations are consistently rejected across both `CREATE TABLE` and `ALTER TABLE` statements. The proposer included SQL examples demonstrating the problematic behavior.

The proposer has submitted a patch set introducing multi-entry indexing for GiST and SP-GiST access methods. This new functionality enables a single heap tuple to generate multiple index entries, akin to GIN's `extractValue`. The primary motivation is to enhance the precision of operators like `@>` and `<@` for composite data types such as multiranges, especially those with gaps, which currently suffer from numerous false positives. Additionally, it provides the first multirange opclass support for SP-GiST. The design integrates an optional `extractValue` support function (proc 13 for GiST, proc 8 for SP-GiST) that decomposes a datum into sub-entries during index insertion and building. During scans, a TID hash ensures result deduplication, and for KNN scans, an early filter is applied. The proposer also outlines semantic considerations for opclass authors, noting that consistent functions will process one sub-entry at a time, often necessitating `recheck=true` for accuracy.

The proposer identified a critical use-after-free bug within the `ri_triggers.c` module, specifically in `RI_FKey_cascade_del`. This vulnerability can lead to a segmentation fault when a DELETE operation is performed on a self-referential table that has `BEFORE DELETE` triggers which also delete rows from the same table. The issue arises during reentrant RI trigger execution if the plancache is invalidated, causing a freed Postgres plan to be used prematurely. To address this, the proposer submitted two patches: one introducing a test case to reliably reproduce the segmentation fault, and another implementing reentrancy guards in `ri_triggers.c`. These guards are designed to maintain a reference count for plans currently in execution, thereby preventing their premature deallocation.

This thread proposes removing an obsolete test case related to the `LISTEN` array growth isolation. The test was identified as a leftover from a previous patch version for the `LISTEN/NOTIFY` optimization. The proposer indicated that a patch to remove this test would be submitted in a separate thread.

The proposer identified an issue where NOTICE messages generated during libpq connection establishment, such as from login triggers, are not correctly logged via ereport() but are instead printed to stderr. This occurs because the libpqsrv_notice_receiver is installed too late in the connection process. The proposer initially suggested adding wrapper functions to install the receiver earlier. A reviewer, however, proposed a more general solution: splitting the libpqsrv_connect() function into two phases, libpqsrv_connect_start() and libpqsrv_connect_complete(), to allow the notice receiver to be set in the interim. The proposer agreed to this refactoring approach.

The proposer introduced a new feature proposal to add a `COPY <t> TO BLACKHOLE` command and a `pg_dump -Fb` format. The motivation stems from current inefficiencies in corruption checking using `COPY to /dev/null` or `verify_heapam()`, and the large disk space requirement for parallel `pg_dump -j` operations that demand a directory format. The `BLACKHOLE` target would discard data, providing a performance optimization over writing to `/dev/null` (benchmarked at 11-14% faster). The `pg_dump -Fb` option would allow parallel dumping without generating output files, thus saving significant disk space on large installations. The proposer is seeking community feedback on the usefulness of these changes.

A proposer introduced a new contrib module, `anyarray`, aiming to generalize `contrib/intarray` functionality for any array type with a default btree opclass. The initial submission contained the patch embedded in the email body, which commenter 1 noted, requesting a proper attachment.

The proposer identified an information leakage bug in the pg_available_extensions view. When the extension_control_path parameter is explicitly set to an empty string, the location column incorrectly displays the absolute system path (e.g., /usr/local/pgsql/share/extension) instead of the documented '$system'. This behavior contradicts the documentation, which states that an empty string for this parameter should default to '$system'. The proposer provided a straightforward patch to correct this, ensuring that '$system' is displayed as expected in this scenario. Multiple reviewers reproduced the bug and confirmed the patch fixes the issue.

The thread addresses a race condition in the async notification mechanism (`async.c`) that can cause `LISTEN` clients to entirely miss `NOTIFY` messages. This occurs when a `NOTIFY` commits in a brief window between a listener registering its queue position and becoming active. During this window, `SignalBackends()` might incorrectly conclude the listener isn't interested and advance its queue pointer past the notification, leading to a "false negative" where a notification is lost. The proposer suggested a fix that involves treating staged `LISTEN` entries as potential listeners when deciding whom to wake. The proposed solution includes three patches: two tests and the fix. A reviewer confirmed the bug and the effectiveness of the fix, also pointing out a test file duplication and another related scenario addressed by the patch.

The proposer identified a bug in the `statext_dependencies_deserialize()` function where an incorrect size validation check was being performed. Specifically, `SizeOfItem` was mistakenly used instead of `MinSizeOfItems`, leading to an erroneous calculation of the expected bytea size. The proposer noted that a similar function for ndistinct extended statistics correctly uses `MinSizeOfItems`, suggesting the issue was a typo. A reviewer confirmed the validity of the bug report, praised the discovery, and indicated that they would fix the issue.

The thread begins with the proposer reporting a bug where `pg_stat_wal_receiver` does not show the `CONNECTING` status for a WAL receiver, which contradicts the original intent for monitoring. The proposer suggests a patch (v1) to display a minimal row with the PID and 'connecting' status when `WalRcv->ready_to_display` is false. A reviewer proposes an alternative patch (v2) that refines how `WalRcv->ready_to_display` is used, splitting the data filling into two steps to ensure `CONNECTING` status is visible without exposing potentially stale connection details. The proposer initially raises concerns about v2's display of `last_msg_send_time` and `last_msg_receipt_time` during the `CONNECTING` state, arguing they could be misleading if showing initial timestamp values rather than actual message activity. The reviewer defends v2, explaining that these values reflect the initialized state of the WAL receiver and can still be useful. The proposer eventually accepts v2, suggesting a documentation update for clarity. However, the proposer then discovers a new, related bug: a `conninfo` leak in the WAL receiver reuse path, where old connection information could persist while in `CONNECTING` or `WAITING` states. The proposer describes the leak and proposes a new patch to address it by only copying primary connection info when switching to `WALRCV_STARTING`, avoiding unnecessary `conninfo` clobbering. The reviewer confirms this new bug is legitimate, affects stable branches, and requests the proposer to submit the patch for backporting.

This thread centers on a review of a patch introducing partial refreshes for materialized views using a WHERE clause. The reviewer raised several concerns regarding the patch's concurrency semantics. Key issues included potential deadlock scenarios arising from the proposed FOR UPDATE + single-CTE approach, particularly in cases of UPSERT conflicts. The reviewer also noted that the CONCURRENTLY behavior for WHERE refreshes appeared counter-intuitive, seemingly making the non-concurrent path more permissive for writers, which deviates from established REFRESH MATERIALIZED VIEW semantics. Documentation for intended guarantees around overlapping partial refreshes and concurrent DML on base tables was also suggested. Despite the valuable use case identified for high-churn refresh workloads, the subsequent messages in the thread did not address these technical points, instead focusing on administrative guidance for the reviewer regarding proper mailing list etiquette, specifically how to reply-all to the original thread.

The proposer identified an inconsistency in the wording of logical replication conflict messages generated by `errdetail_apply_conflict` in `conflict.c`. The proposer suggests that these closely related messages, which cover various conflict types like insert/update/delete conflicts and origin differences, should be revised to have a more uniform and consistent phrasing. A detailed list of current message variations was provided to illustrate the problem.

This thread provides a review of a patch related to a "ternary reloption type." The reviewer identified a key issue where the `default_val` field within the `relopt_ternary` structure was incorrectly typed as `int` instead of `pg_ternary`. This type mismatch prevents the field from correctly holding the `PG_TERNARY_TRUE/FALSE/UNSET` values. The reviewer suggested changing the type for `default_val` and also proposed minor code style improvements for argument alignment in related function definitions. The feedback is concise and points to a direct fix.

The proposer introduced an improvement for PostgreSQL's extended statistics, specifically addressing cases where multi-column Most Common Value (MCV) combinations are not present in the MCV list. Currently, the planner falls back to individual independent statistics, often leading to significant overestimations. A test case was provided to illustrate this, showing a query estimated to return 5909 rows when the actual count was zero. Two approaches were suggested to enhance selectivity estimation for these missing combinations: (1) Cap the selectivity using the frequency of the least common item in the MCV list. (2) Employ a method similar to single-column MCVs by incorporating `ndistinct` information to estimate frequencies. The proposer emphasized that these methods would be computationally inexpensive. A reviewer provided feedback on both proposals.

This thread discusses the behavior of the LIKE operator when used with nondeterministic collations, particularly focusing on the relationship between prefix matching and range-based comparisons. An earlier proposal suggested an equivalence between LIKE 'prefix%' and a specific range query. A reviewer questioned if this equivalence holds across all possible collation rules. A commenter responded, arguing that the fundamental definition of a collation necessitates this prefix-to-range connection, implying that any "strange rule" breaking this would mean it's not a valid collation. The conversation is at a conceptual stage, exploring the theoretical underpinnings of collation behavior.

The thread delves into the fundamental definition of a "character" within PostgreSQL and SQL, specifically in the context of the LIKE operator and Unicode. An earlier point from a reviewer emphasized that PostgreSQL defines a character as a single code point, arguing that changing this to a "grapheme cluster" (a sequence of code points forming a perceived character) would be a breaking change for many functions. A commenter contended that the single code point definition is inadequate for Unicode, where many "characters" require multiple code points. While acknowledging the breaking nature of such a change for existing string manipulation functions, the commenter advocated for LIKE to adopt grapheme cluster awareness, particularly where current behavior is counter-intuitive to human understanding.

A buildfarm failure was reported for the test_slru module on the gokiburi host, affecting only the REL_16_STABLE branch. The issue manifests as an assertion failure related to LWLock initialization, specifically Assert("LWLockHeldByMe(TestSLRULock)"). The failure is reproducible and a backtrace was provided. The problem appeared after two recent, seemingly unrelated commits. The proposer is actively investigating the root cause of this LWLock-related issue.

This thread reports a significant performance regression introduced by a recently committed change aimed at supporting LIKE with nondeterministic collations. The reporter indicates that the commit, though intended to enhance functionality, has caused `psql \d` and various database tests to become much slower. This slowdown is attributed to the fact that indexes are no longer being utilized in scenarios where they should be. The reporter highlights that this issue was previously brought up in another thread but received no attention, prompting this follow-up to ensure the regression is addressed. The implication is that corrective action or further investigation is required to mitigate the performance impact of the committed feature.

This thread concerns a minor typo fix within the OAuth functionality. The proposer submitted a patch to correct a forgotten quote in an error message. The fix was quickly reviewed and accepted, with the reviewer indicating that it would be applied.

This thread presents a reviewer's initial observations and questions regarding the proposed `COPY ON_ERROR_TABLE` patch. The reviewer highlights potential complexities arising from the interaction of this feature with the existing `COPY` multi-insert path, specifically concerning `CopyMultiInsertBuffer` and `table_multi_insert()` batching, and how row-level errors might impact buffer consistency, trigger visibility, and index management. The reviewer suggests disabling multi-insert batching initially for simplicity and correctness. Additional concerns include clarifying the transaction behavior for rejected rows (whether they should rollback with the main `COPY` transaction) and handling recursive failures if the error table insertion itself fails. These are presented as observations rather than confirmed issues.

The proposer reported and provided detailed reproduction steps for a known bug where VACUUM FULL or CREATE INDEX can fail with "ERROR: missing chunk number 0 for toast value". The bug stems from a discrepancy in transaction horizon computation between a main table's VACUUM and its associated TOAST table's VACUUM. Specifically, ComputeXidHorizons for the main table respects local database transactions, preventing old tuples from being immediately removed. However, when the TOAST table is vacuumed later, an external transaction holding up the main table's horizon might have committed. With no other active processes in the same database, the TOAST VACUUM can wrongly determine an OldestXmin that allows the TOAST tuples to be removed. Subsequently, a CREATE INDEX on the main table, calculating its own OldestXmin (which now considers the external transaction), expects the RECENTLY_DEAD main table tuple's TOAST value to exist but finds it missing. The proposer developed a prototype patch that reuses the parent table's OldestXmin when vacuuming a TOAST table to ensure consistent horizons.

This thread proposes an enhancement to psql's `\dRp+` command, aiming to prevent it from listing individual tables if they are already encompassed by a `FOR TABLES IN SCHEMA` clause within a publication. The proposer argued that the current behavior creates confusing output, especially when row filters or future `EXCEPT` clauses are involved. Commenters supported the idea, leading to the incorporation of a similar logic to improve the `\d+` command, ensuring tables are not redundantly displayed. A discussion on including a PostgreSQL 15 version check for catalog access in psql was resolved by adding it as a precautionary measure. The patch has undergone several revisions and is now considered complete and ready for a committer's review.

The proposer identified three issues in `pg_restore_extended_stats()`. The first concerned inconsistent key verification behavior, where `strncmp()` was used for prefix matching instead of exact string comparison, leading to silent discarding of malformed keys without warnings. The second issue pointed out an incorrect number in a warning message. The third issue highlighted inconsistent `heap_freetuple()` calls in `pg_clear_extended_stats()`, suggesting memory leaks in certain error paths. A reviewer confirmed these issues, agreeing that the prefix matching is a silent data loss problem and the other two are minor but valid bugs. The reviewer committed to fixing all reported issues.

The proposer reports a recurring buildfarm failure in `035_standby_logical_decoding`, where `pg_recvlogical` terminates unexpectedly. The core problem appears to be a FATAL error message from the server being lost or truncated within libpq, resulting in a generic "server closed the connection unexpectedly" error instead of the specific conflict message. The proposer successfully reproduced the issue and provided detailed logs, including truncated raw read buffers from libpq, indicating that libpq might not be correctly handling or reporting the full server error message. The issue has been observed before without a clear explanation.

The proposer is restarting a discussion to implement mid-transaction flushing of PostgreSQL statistics. Building on previous feedback, the new patch introduces both SQL and C APIs to allow users and extensions to trigger a statistics flush on demand. The SQL API can target a specific PID, flushing immediately for the calling backend or signaling other backends to flush at their next interrupt or main-loop iteration. The C API is for the calling backend only. The proposal differentiates between statistics that can be flushed immediately (e.g., scans, fetches, IO, WAL stats) and those that must still be deferred until transaction end due to their dependency on transaction outcome (e.g., transactional write counters like inserted/updated/deleted tuples).

The proposer identified a critical bug in the `pg_stash_advice` worker that leads to a cluster restart loop. If the `pg_stash_advice.tsv` persistence file contains a stash name of 64 bytes or more (equal to or exceeding `NAMEDATALEN`), the worker crashes on startup with an assertion failure in `dshash_strhash()`. This happens because the file parser lacks a length check, unlike the SQL-level input path, causing an invalid string length to be passed to a function configured for a fixed key size. The postmaster interprets this as a crash, leading to continuous restarts and preventing the cluster from reaching a stable state. In production builds, this would result in silent truncation and potential hash collisions. The proposer attached a patch to address the issue by adding the necessary length validation to the file parser, mirroring existing checks, and included a TAP test.

The proposer introduced a patch to add a `NESTED_STATEMENTS` option to `EXPLAIN`, allowing users to directly view execution plans for SQL statements within functions or procedures, bypassing the need for `auto_explain` and server logs. The feature works by temporarily installing executor hooks to capture and display nested plans. A reviewer identified two server crashes: one occurring after an error during `EXPLAIN (ANALYZE, NESTED_STATEMENTS)` followed by other queries, and another when an `EXPLAIN (ANALYZE, NESTED_STATEMENTS)` call was nested within another. A memory leak due to plan allocation in `TopMemoryContext` was also reported. The proposer subsequently released a v2 patch, addressing these issues by implementing `PG_TRY/PG_FINALLY` for robust hook cleanup, a reentrancy guard for nested `EXPLAIN` calls, and a dedicated memory context for captured plans to prevent leaks.

This thread discusses moving critical checks for `FOR PORTION OF` clauses, specifically regarding Foreign Data Wrappers (FDWs) and volatile functions, out of the analysis phase and into the planner/executor. The proposer noted that these checks should be deferred to ensure the stability of the system and proper handling of child partitions. Patches for both aspects were submitted. A reviewer clarified that this issue, being a bug introduced in PG19, should not be a commitfest entry but rather listed as an "open item" to be fixed before the PG19 release. The proposer acknowledged this guidance and added the item to the PostgreSQL Open Items list.

The thread starts with a user reporting non-deterministic table ordering in `pg_dump` output, which complicates schema migration validation. The user found that two identical schemas produced `pg_dump` outputs with different ordering for three specific tables, leading to large, artificial diffs. A core developer confirmed that `pg_dump` order should be deterministic and suggested checking database locales or non-ASCII object names. The user clarified they use UTF-8 and C locale, and revealed a client `pg_dump` version (18.1) higher than the server (14.22). During investigation, the user identified what they believed was a bug in `pg_dump`'s handling of inheritance, specifically the `NOT NULL` constraint on a child table. The core developer clarified that the syntax was valid in `pg_dump` 18 but not 14, and explained that the order inconsistency was unlikely to be demonstrated with just two tables. The user acknowledged the clarification and stated they would continue to investigate the cause of the ordering problem.

The proposer identified undocumented behavior in `ALTER TABLE ... ATTACH PARTITION` where invalid indexes on a partition are silently skipped, leading to the creation of new indexes instead of attaching the existing ones. This behavior, introduced in a previous commit, could surprise users. The proposer submitted a documentation-only patch to clarify this. A reviewer agreed with the need for documentation and proposed an alternative, more concise wording that explicitly reinforces the requirement for an index to be 'valid' for attachment.

This thread introduces a proposal to enhance `vacuumdb` by adding an `--exclude-database (-D)` option. This new feature would allow users to skip specific databases when performing `vacuumdb --all` operations, addressing a common need in production environments where certain databases might need to be excluded from routine maintenance. The proposer provided a detailed explanation of the motivation, usage examples, and confirmed that the patch passes all existing `vacuumdb` TAP tests. New TAP tests and a comprehensive standalone test script were also included to cover various exclusion scenarios, multiple exclusions, and error handling, with all tests passing.

This thread addresses a bug in `pg_recvlogical` where it failed to preserve group permissions on its output files, despite documentation stating otherwise. The issue stemmed from output files being created with a hard-coded mode rather than respecting the source cluster's group permissions. The proposer submitted a patch to use `pg_file_create_mode` and update the documentation. A reviewer provided a TAP test to verify the fix. The proposer then refined the TAP test to cover both scenarios: when group access is enabled and when it's disabled, ensuring `pg_recvlogical` correctly applies permissions (0640 vs 0600). The patch, including the improved test (for master branch), has been committed.

A proposer identified a minor syntax error in the documentation for the `pg_restore_extended_stats()` function, specifically a missing comma in a SQL example. The proposer reported the issue with a clear description of the mistake. A reviewer acknowledged the report and promptly confirmed that a fix would be applied. The reviewer then committed the necessary change to correct the documentation. The proposer subsequently thanked the reviewer for the quick resolution, confirming the successful update of the documentation.

The proposer initiated a discussion to simplify the `ProcessStartupPacket()` function by removing its `ssl_done` and `gss_done` arguments. This simplification was suggested because a recent commit had reduced the number of callers of this routine to just one, making the arguments redundant. A patch was provided targeting HEAD (v20). Two reviewers quickly supported the change, with one suggesting that it could also be applied to v19. The proposer agreed with the suggestion. The patch was subsequently applied to HEAD, marking the successful completion of the cleanup.

This thread proposes a trivial fix to a comment within the pgstat_assoc_relation() function. The proposer observed that the comment begins with "Else," suggesting it is a remnant from a previous code refactoring where the function was split. The proposal is to simply remove the redundant "Else" to improve clarity.

This thread addresses an unbounded memory growth issue in the `pg_sync_replication_slots()` function when it retries operations within a single SQL function call. Unlike the slotsync worker, it lacks transaction boundaries between retry cycles, leading to the accumulation of allocations for remote slot data (names, plugins, databases) and other per-cycle data. The proposer suggested a patch to run each manual retry cycle within a short-lived memory context, resetting it before each attempt, and included two local cleanups for tuple slots and list containers. Commenter 1 generally supported the idea but suggested fixes for memory context deletion on failure and improved comments. Commenter 2 agreed with the general approach of preventing memory accumulation but disagreed on the need to delete the memory context on failure, citing transaction abort behavior. Commenter 3 inquired about the amount of other unrelated memory allocated per cycle. The proposer explained the problem was found via code review, not observed memory growth, and detailed additional small accumulating allocations, favoring the memory context approach for explicit lifetime management. The proposer then provided measurement results showing an initial 192 KiB growth on HEAD for 100 logical slots, which was significantly reduced after implementing targeted cleanups for copied `RemoteSlot` strings.

This thread presents a review of the `createPartitions()` function in `pgbench.c`. The proposer identifies several potential robustness concerns that, while not yet reproduced as failures, warrant review. These observations include a possible integer overflow in the `part_size` calculation, a reliance on `Assert(partitions > 0)` for runtime safety, the reuse of `PQExpBuffer` without explicit resetting, and potential edge cases related to uneven `RANGE` partition boundaries. The proposer offers a concrete suggestion to improve the `part_size` calculation by explicitly casting to `int64` to prevent overflow. The thread is currently in its initial proposal stage, awaiting further discussion or action.

The proposer identified a bug in the `COPY (on_error set_null)` option. The issue arises because the `cstate->domain_with_constraint` array is allocated based on the length of the specified column list but is later accessed using the actual attribute number. This mismatch can lead to an out-of-bounds read and incorrect behavior, specifically demonstrated by a `NOT NULL` domain column accepting a NULL value when it should fail during an `ON_ERROR SET_NULL` operation with an invalid input. A clear reproduction case was provided, and the proposer suggested a fix that aligns the allocation and access of the array by using the actual number of table attributes. A commenter then pointed out that this issue appears to be a duplicate of an already reported bug.

The thread focuses on re-adding regression tests for `ltree` and `intarray` extensions, which were previously removed due to stack overflow issues on specific buildfarm architectures (ppc64, s390x) when compiled without certain optimizations (e.g., `-O0`). A reviewer provided detailed insight into the root cause: tail-recursion in `findoprnd()` not being optimized by all compilers/architectures, leading to excessive stack usage for right-deep query trees. The proposer introduced new tests designed with a balanced binary tree structure to prevent deep recursion. After a commenter verified the new tests passed under conditions that previously caused failure, the proposer confirmed successful buildfarm results and backpatched the changes to v14.

The thread discusses a bug in the refint module where check_foreign_key() incorrectly reuses cached prepared plans for cascade UPDATE actions, leading to propagation of incorrect key values. The proposer initially suggested a fix (v1) to prevent caching cascade UPDATE plans. A reviewer highlighted broader issues with the plan cache's lack of invalidation and suggested using trigger OID as a key, or removing the cache altogether. Following this, another reviewer proposed outright removal of the refint module, given its superseded status and multiple bugs, a suggestion that received support. The proposer then submitted v3, which completely removes the private SPI plan cache from refint for both check_primary_key() and check_foreign_key(), preparing plans per invocation. The discussion continued on refining the patch by removing historical comments and reformatting, with v4 addressing these points and a follow-up pgindent patch planned. A separate thread for refint module removal is also planned.

The proposer highlighted an inconsistency in `postgres_fdw` where the `use_scram_passthrough` option's server-level setting incorrectly overrides the user mapping setting, contrary to the expected precedence for per-user options. Reviewer 1 confirmed this behavior is incorrect and noted `dblink` suffered from the same issue. Reviewer 1 then provided patches to correctly prioritize the user mapping setting for both extensions. During review, the proposer identified an additional bug in `dblink`: `use_scram_passthrough` could be set on `dblink_fdw` itself but had no functional effect. Reviewer 1 addressed this with a new patch, ensuring the option is validated only in foreign server or user mapping contexts. Discussion also covered relocating a test for this new fix to `sql/dblink.sql` and the desirability of backporting all three changes to v18 for consistency, aligning with existing precedence rules for similar options like `sslkey`.

This thread highlights a potential bug in the `numeric_poly_deserialize` and `numeric_deserialize` functions. The proposer points out that these deserialization functions, intended for aggregate states that require `sumX2` (such as `var_pop` and `stddev_pop`), incorrectly initialize the `calcSumX2` flag to `false`. While this might not affect the in-tree `deserialize` then `combine` pipeline, it causes issues for external callers (e.g., extensions) that deserialize state and then apply transition calls, leading to `sumX2` not being accumulated and thus yielding incorrect results. The proposer noted that `numeric_combine` correctly sets this flag. A two-line patch was attached, and the proposer is seeking feedback on whether this fix is necessary or if the current behavior is intentional.

A patch was submitted to correct a spelling inconsistency in comments within `waiteventset.c`, standardizing "writeable" to "writable". The proposed change is minor and purely stylistic. However, the reviewer encountered a procedural issue: the patch's author was identified by a company name rather than a personal name. The reviewer expressed discomfort committing the patch without proper personal attribution, citing difficulties in referencing the original author in the future. The reviewer requested guidance on whether to proceed with no author, or to simply leave the minor typo unfixed. The core technical merit of the patch is not the issue, but rather the administrative process for committing it.

The proposer identified an inconsistency in `postgres_fdw`'s `ANALYZE` behavior: when `restore_stats` is disabled, it uses the foreign table owner's user mapping for remote data sampling, but when `restore_stats` is enabled, it uses the executing user's mapping for fetching remote statistics. This can cause `user mapping not found` errors. The proposer submitted a patch to unify this by always using the table owner's mapping. The original implementer defended the current behavior, citing security (lower privilege needed for stats import) and arguing that the issue is rare. The proposer countered that the inconsistency is confusing and problematic, especially when a fallback mechanism implicitly switches to the owner's mapping, potentially requiring two separate user mappings for a single `ANALYZE` operation.

This thread addresses a bug where the `LIKE` operator failed to correctly match literal backslashes when used with non-deterministic collations. The proposer identified that the issue stemmed from redundant backslash escaping within `like_match.c`, a behavior introduced during the implementation of `LIKE` support for non-deterministic collations. An initial patch was provided with a regression test to fix this. A reviewer confirmed the patch resolved the bug but suggested improving the code's readability and robustness by using an `afterescape` flag, similar to existing logic in `do_like_escape`, instead of relying on implicit outer loop details. The proposer agreed to this suggestion and also noted the need to handle multibyte encodings more carefully, proposing to use `NextChar` for character copying to prevent potential issues with byte-by-byte processing.

The thread addresses a bug in the `COPY TO` command when used with partitioned tables where a partition's column order differs from its root table. The proposer discovered that the `build_attrmap_by_name_if_req()` function was called with incorrect arguments, leading to `COPY TO` outputting NULL values. The proposer provided a clear reproducible example and a straightforward fix involving reversing the order of arguments to the function. Reviewer 1 and reviewer 2 confirmed the bug and the validity of the proposed fix. Reviewer 2, who was responsible for the original commit, took ownership of integrating the fix. The proposed solution was committed, resolving the issue.

This thread discusses a potential issue with the `IGNORE NULLS` support for window functions, specifically concerning how nullness is cached for volatile arguments. The proposer observed that the current implementation caches nullness for arguments to avoid re-evaluation, which can lead to unexpected behavior if a volatile argument's nullness changes between the initial check and later evaluation. The proposer proposed a solution where the nullness cache would only be used for arguments safe to reuse, treating non-cacheable (volatile) arguments' nullness as unknown, requiring re-evaluation when needed. A reviewer agreed with this approach, outlining it as a reasonable choice among alternatives. The reviewer suggested minor code refactoring to integrate the cacheability check directly into the `get_notnull_info()` and `put_notnull_info()` functions for better encapsulation. The proposer provided a revised patch incorporating these suggestions, which the reviewer subsequently committed.

This thread addresses a critical false-negative conflict detection issue in logical replication. The problem arises when a `ReplOriginId` is reused after a subscription is dropped, causing a new subscription to incorrectly identify previously replicated changes as its own, thereby skipping conflict detection. The proposer introduced two approaches: 1) nullifying old origin IDs in `commit_ts` data on subscription drop, which is comprehensive but potentially expensive and not crash-safe without WAL logging; and 2) adding a creation timestamp to each replication origin and comparing it during conflict checks, deemed lightweight and crash-safe. Reviewers confirmed the problem's significance. A separate scenario involving publisher switching was clarified as outside the current replication model's scope. While LSN matching was considered as an alternative to timestamps, it would necessitate extending the `commit_ts` structure, making Approach 2 (timestamps) the more practical option currently under consideration.

This thread focuses on a reported seg-fault that occurs when `FOR PORTION OF` syntax is used with virtual generated columns. The proposer created this dedicated thread to track the development and application of a fix for this specific bug, referencing an earlier discussion where the issue was initially brought up. The proposer clarifies that while their initial approach involved a check during the analysis phase, they have since developed a standalone patch, now at v2, to address this interaction more directly.

This thread initiates a discussion about the possibility of implementing an extensible SQL parser in PostgreSQL. The proposer references a recent article on DuckDB's runtime-extensible parsers, suggesting it as a potential model for PostgreSQL, and recalls previous discussions on this topic. A commenter then shares their ongoing project, 'Lime', which is a replacement for PostgreSQL's existing flex and bison-based parser. The commenter's goal with 'Lime' is to enable runtime extensibility of the parser, which would provide extension authors with more advanced capabilities. The work is described as not yet stable but is presented as a basis for further discussion on the topic.

The proposer identified a bound-overlap bug in ALTER TABLE ... SPLIT PARTITION and other areas needing improvement, including unclear documentation for splitting with a DEFAULT partition and a need for better error messages. The initial proposal included multiple patches, with a reviewer confirming that patches 0001-0003 were ready. The proposer then identified a collation-related issue in patch 0004 concerning LIST partitions and provided a revised version. The reviewer subsequently committed patches 0001-0003 and revised patch 0004, adding further tests. The discussion continued around the details of patch 0004, focusing on correct handling of collations and ensuring proper bound comparisons for LIST partitions.

This thread addresses a bug where a REPACK decoding worker process and its temporary replication slot were not properly cleaned up when the main REPACK session terminated via a `FATAL` exit (e.g., `pg_terminate_backend`). The initial proposer identified that `FATAL` exits bypass `PG_FINALLY` blocks, preventing the worker's cleanup function from being called. The proposer's first patch used `on_proc_exit` callbacks, but reviewer 1 found it caused a segfault due to use-after-free, suggesting `before_shmem_exit` instead. Committer 1 then proposed `PG_ENSURE_ERROR_CLEANUP()` as the most robust solution, which handles both `ERROR` and `FATAL` exits, automatically cancels on normal completion to prevent slot leaks, and runs before memory contexts are destroyed. The proposer's v3 patch implemented this, successfully resolving the issues and passing tests. Committer 1 subsequently pushed the fix, along with further refinements to `stop_repack_decoding_worker()` to improve memory handling. Commenter 1 then inquired about a potential omission of `shm_mq_detach()`, leading to a brief discussion about automatic detachment of shared memory queues.

The thread initiates with a proposer highlighting a critical flaw in the `vacuumlo` utility: its silent deletion of large objects (LOs) referenced by columns defined as domains over `oid` or `lo` types, despite this behavior being documented. This leads to irreversible data loss. The proposer suggests either modifying `vacuumlo` to resolve domain types to their base types or to at least issue a warning. Commenter 1 supports documentation improvements and explores user-specified queries, while Commenter 2 advocates promoting the `LO` extension and `lo_manage()` to reduce `vacuumlo`'s role. The discussion then delves into enhancing `vacuumlo`'s detection capabilities for LOs in domains, composite types, and arrays, acknowledging the potential for more complex query generation. Ultimately, participants agree on a multi-faceted approach involving `vacuumlo` improvements, clearer documentation, and encouraging `LO` extension adoption.

This thread addresses a bug in the `json_path` method `split_part()` where it does not honor the `silent => true` option when encountering invalid arguments, such as a zero field position or an out-of-range integer. The proposer demonstrated that, unlike the `.decimal()` method, `split_part()` immediately raises an error instead of suppressing it. The root cause was identified as `split_part()` directly using `numeric_int4()` for argument parsing, while `.decimal()` uses `numeric_int4_safe()`. A patch was proposed to switch `split_part()` to use `numeric_int4_safe()` and integrate with the jsonpath error handling mechanism. Commenter 1 confirmed the bug and verified the patch's effectiveness. Reviewer acknowledged the problem and confirmed they would double-check the relevant code areas, which they later reported doing without finding similar issues.

The proposer initiated a discussion on improving the scalability of pg_stat_statements, highlighting three primary issues: high spinlock contention, performance bottlenecks during hash table deallocation under exclusive locks, and query text file bloat with inefficient garbage collection. The proposed solution leverages the existing PostgreSQL statistics collector (pgstat) system, which offers local stat writing, periodic flushing to shared memory, and dynamic resizing capabilities. The work builds on recent PostgreSQL developments in pluggable cumulative statistics and serialization callbacks. The proposer later reorganized the patches and fixed an issue causing CI failures related to parallel query execution, providing an updated series.

The thread began with the proposer identifying and fixing a bug in `psql`'s tab completion for `REPACK`'s boolean options (`ANALYZE`, `CONCURRENTLY`, `VERBOSE`). The original implementation used `TailMatches` incorrectly, requiring all options to appear sequentially instead of as alternatives. The proposer's patch, which switched to pipe-separated alternatives, was reviewed and committed. During subsequent testing, reviewer 1 discovered two additional related bugs in `REPACK`'s parsing: `CONCURRENTLY OFF` was incorrectly treated as an unrecognized option, and specifying the same option multiple times did not always honor the last value (e.g., `ON` overriding a final `OFF`). A second patch addressing these parsing issues was also proposed, reviewed, and committed. The thread concluded with a discussion about potential future refactoring to centralize the `DefElem` list processing logic across commands like `REPACK`, `VACUUM`, and `EXPLAIN` to prevent similar bugs.

The proposer identified a bug where `ALTER TABLE ... ALTER COLUMN ... SET EXPRESSION` failed to rebuild `CHECK` constraints that referenced a generated column using a whole-row `Var`, potentially leaving the table in an inconsistent state. The proposer's initial patch aimed to rebuild all `CHECK` constraints. Commenter 1 then expanded the scope to include whole-row references in indexes and RLS policies, demonstrating a more comprehensive solution across several patch versions. Discussion revolved around the detailed implementation, appropriate error messages, and whether to disallow `SET EXPRESSION` for whole-row policy references. Through several iterations, the patch was refined to correctly revalidate `CHECK` constraints and rebuild indexes, while safely ignoring whole-row policy references for `SET EXPRESSION` as they do not require action. The latest review confirmed the patch's effectiveness and correct behavior.

The proposer initiated a refactoring effort to make the memory and ownership semantics of NumericVar explicit, reorganizing helper functions for clarity and maintainability. The goal is to establish a clear, consistent internal contract for digit-buffer acquisition, release, borrowing, and writing, rather than altering numeric algorithms or immediately boosting performance. The proposer released multiple versions of the patch, addressing a bug where set_var_from_var() could pass NULL to memcpy() for zero NumericVar and fixing a test instability. The latest update (v4) specifically ensured the re-inclusion of the set_var_from_var() fix.

The proposer reported a bug where SQL-callable replication slot functions (like pg_replication_slot_advance) can fail to release an acquired replication slot if an error occurs and is caught by a PL/pgSQL EXCEPTION block. This leads to a stale MyReplicationSlot process-global variable, causing an Assert crash in debug builds or silently orphaning the slot in release builds. Orphaned slots prevent other sessions from acquiring them and block vacuum and WAL deletion. The proposer provided a patch using PG_TRY/PG_CATCH blocks to ensure ReplicationSlotRelease() is called on error. Reviewers confirmed the approach, but raised questions about handling temporary logical replication slots which ReplicationSlotRelease() might not fully drop, and identified other functions (pg_copy_logical_replication_slot(), pg_logical_slot_get_changes()) that might suffer from similar issues, requiring a broader fix.

This thread discusses an optimization for `GRAPH_TABLE` path generation. The proposer introduced a patch for "early pruning" during Depth-First Search (DFS) path construction. This change aims to improve performance by checking edge-vertex adjacency constraints proactively, thereby avoiding the enumeration of infeasible full-length paths, a common issue leading to memory exhaustion. Commenter 1 reviewed the patch extensively, confirming its correctness, architectural soundness, and positive impact on performance, while also suggesting minor improvements and requesting regression tests, which the proposer addressed in subsequent versions. However, Commenter 2 raised concerns about the potential complexity this "failing early" strategy might introduce for future advanced features like variable-length or embedded path patterns, suggesting a delay or further discussion on its long-term compatibility. The proposer provided profiling data to demonstrate the significant time consumed by path expansion.

This thread re-opens the discussion on parallelizing INSERT ... SELECT queries, a feature previously committed and then reverted due to overhead concerns with partitioned tables. The proposer rebased an old patch and summarized the historical context and challenges. The main discussion point revolves around a "declarative approach" involving a pg_class attribute to store parallel safety information. The proposer advocates for automatically updating this flag, while a commenter highlights the complexity, locking issues, and race conditions associated with such an automatic update, particularly with concurrent DDLs affecting functions used in expressions. The proposer acknowledges the complexity but questions the frequency of such operations in production. An alternative idea of fully materializing the SELECT result before INSERT is also brought up, which could simplify concurrency but might limit future extensions to UPDATE/DELETE due to EvalPlanQual (EPQ) concerns. The discussion is evaluating fundamental design choices and their long-term implications.

This thread is an RFC proposing to add EXPLAIN (ANALYZE, WAITS) functionality to PostgreSQL. The proposed feature would report completed wait intervals observed during statement execution, attributing them to both statement-level and plan-node levels. Statement-level waits would include parallel worker waits, and plan-node attribution would be inclusive, meaning a wait is attributed to all active nodes when it begins. The implementation uses fixed-size accumulators to avoid allocation overhead during wait-end accounting, with an overflow mechanism for additional distinct wait events. The proposer has outlined several key design questions for discussion, including the option name (WAITS vs WAIT_EVENTS), the inclusive per-node attribution semantics, the fixed accumulator size and overflow handling, and the hot-path overhead. Initial versions of the patch have been submitted, with subsequent versions focusing on improving regression test stability.

The proposer identified an asymmetric bug in the `ParseVariableDouble()` function within `src/bin/psql/variables.c`. The function correctly rejected values below its minimum bound but incorrectly assigned values exceeding its maximum bound, despite logging an error. This behavior violated the function's contract that `*result` should not be modified on unsuccessful validation. A user-visible example was an out-of-range `WATCH_INTERVAL` variable being reported as invalid but still set. The committer acknowledged the bug and committed the fix, which also included backpatching to an earlier version and adding a new test case to ensure correct behavior.

The thread discusses a bug where dropping a label or property from a property graph, which is used by a view created with GRAPH_TABLE, causes a "cache lookup failed for label" error when querying the view. The proposer initially reported the issue and provided a patch. Due to the proposer's unavailability, a reviewer took over the patch development. The root cause was identified as missing dependency tracking for GraphLabelRef and GraphPropertyRef nodes in views. A new patch was developed that adds appropriate dependency walker cases, preventing the problematic ALTER PROPERTY GRAPH operations if a view depends on the label or property. Multiple reviewers provided feedback, leading to several patch versions, with the latest incorporating comprehensive regression tests covering label and property drops in various contexts, including GRAPH_TABLE pattern and column lists. The patch is now marked as "Ready for Committer".

This thread addresses an assertion failure encountered when using LATERAL GRAPH_TABLE with patterns matching multiple path queries. The proposer identified the bug, occurring in create_lateral_join_info when GRAPH_TABLE is used with UNION ALL for multi-label patterns, leading to !bms_is_member(rti, lateral_relids) assertion. The root cause was traced to rewriteGraphTable() bumping outer Vars for the initial subquery, but generate_setop_from_pathqueries() failing to bump Vars again when wrapping each path query in further subquery RTEs for the UNION ALL operation. This caused the lateral reference to incorrectly collapse onto the GRAPH_TABLE's own RTE. The proposed fix involves incrementing the sublevels_up for Vars within each lquery before it's wrapped in an RTE_SUBQUERY. A reviewer provided feedback on code comments, requested a clearer explanation of the connection between varlevelsup, subquery RTE addition, and the assertion failure, and suggested refining the provided test cases.

This thread discusses the proposal and implementation of a conflict log history table for PostgreSQL's Logical Replication feature. The proposer introduced a series of patches (up to v37) to create a system-managed `pg_conflict` schema and associated tables to record replication conflicts. Key discussion points include the design of the `ConflictLogDest` enum, handling of schema renaming for `pg_conflict` (comparing it to `pg_catalog`), and the management of internal dependencies for the conflict log tables. Reviewers provided detailed feedback on code structure, commit messages, documentation accuracy, and test cases. Specific suggestions were made regarding the naming and refactoring of dependency management functions, ordering of schema definitions, and clarification of documentation related to conflict logging behavior and JSON array descriptions. The broader implication of preserving subscription OID was also raised as a separate but related concern. The overall aim is to refine the implementation for robustness, clarity, and maintainability.

The proposer observed that the `pg_stat_get_lock()` function consistently returns 12 rows, yet its `prorows` estimate in `pg_proc.dat` is defined as 10. This discrepancy leads to an inaccurate row count estimate for the planner. The proposer submitted a patch to correct the `prorows` value to 12, thereby improving the planner's accuracy, given that the number of lock types is stable. The patch also includes minor adjustments to function comments in `pgstat_lock.c`. The proposer subsequently rebased the patch, indicating continued maintenance and readiness for review.

This thread proposes a patch to add cross-type integer operator support (int2, int4, int8) to the btree_gist GiST operator families. Currently, GiST indexes only work with exact type matches, preventing the planner from using an index when a query uses a compatible but different integer type (e.g., int8 column compared with an int4 literal). The proposed solution extends the gist_int2_ops, gist_int4_ops, and gist_int8_ops families with cross-type comparison and KNN-distance operators. Instead of registering new support functions for each cross-type combination, the patch dispatches cross-type queries directly within existing consistent and distance functions, leveraging existing subtype information. This aims to improve index usability without requiring explicit casts in queries. A patch and reproduction scripts were submitted.

The thread discusses a potential discrepancy in PostgreSQL's Row Level Security (RLS) implementation concerning `UPDATE/DELETE FOR PORTION OF` commands. The proposer observed that when these commands insert temporal "leftover" rows, they bypass `INSERT RLS WITH CHECK` policies, even though these are newly inserted rows. The proposer provided a SQL example demonstrating this bypass and suggested a patch to enforce `CMD_INSERT` RLS policies for such operations. A commenter, however, argued that skipping these `INSERT RLS` checks is the correct and intended behavior, consistent with how ACL checks are bypassed for leftovers. The commenter posited that leftover rows semantically preserve existing history rather than creating new data that would be subject to `INSERT` policies. The commenter offered to prepare a documentation patch to clarify this behavior, indicating a preference against the proposed functional change.

The thread discusses a proposal to refactor pg_strncoll(), pg_strnxfrm(), and pg_strnxfrm_prefix() to allow a -1 length argument to signify NUL-terminated strings, similar to ICU's API. The initial proposer intended this to simplify the API. However, a reviewer immediately raised concerns that this change would complicate compiler annotations for memory access (e.g., ubsan), making them less accurate. The reviewer also argued it would lead to more complex code with numerous conditional branches. The proposer accepted this feedback, acknowledging the interference with useful debugging tools. The proposer then submitted a revised patch that avoids the -1 length convention, which was positively received by the reviewer, who highlighted its benefits for instrument-ability and potential runtime performance. The proposer announced plans to commit the revised patch.

This thread addresses a critical `pg_upgrade` problem concerning logical replication origins. When upgrading a subscriber, `pg_commit_ts` data (containing replication origin IDs or roidents) is copied directly. However, new subscription OIDs and roidents are assigned during upgrade, leading to mismatches and `update_origin_differs` conflicts. The proposer initially aimed to preserve roidents. Commenters suggested a more fundamental change: preserving subscription OIDs, which would stabilize origin names and, thus, simplify roident preservation. A rebased patch (v3) incorporated this, allowing all replication origins from the old cluster to be copied with matching names and IDs. The patch is now undergoing detailed review, with feedback on backward compatibility (supporting PG17+), code style, potential SQL injection, locking mechanisms, and catalog types. The proposer is actively addressing these comments and iterating on the patch.

This thread focuses on fixing overflow and underflow issues in PostgreSQL's statistical aggregate functions. The proposer initially submitted a patch to address `regr_r2()`'s direct computation of `(Sxy * Sxy) / (Sxx * Syy)`, which can lead to results like NaN due to extreme scale values. Reviewer 1 provided a refined patch, suggesting to keep the stabilization logic local to `float8_regr_r2()` and improve test cases, which was accepted by reviewer 2. The discussion then expanded to include `regr_intercept()`, which also exhibits similar computational vulnerabilities. Reviewer 1 proposed a more robust solution for `regr_intercept()` using `frexp()` and `ldexp()` to handle extreme values, which is currently under review.

This thread addresses a critical concurrency bug in the `ProcKill()` function, present in PostgreSQL versions since 9.6. The proposer identified a race condition where a lock-group leader's `PGPROC` can be returned to the freelist while its `procLatch` is still owned, leading to a `PANIC: latch already owned by PID ...` when the slot is recycled. The proposer detailed the specific interleaving causing the bug and provided initial patches. Reviewer 1 confirmed the issue's reality and severity, noting similar reports from other users, and helped rebase the patches for clarity. Reviewer 2 provided in-depth feedback on the core fix—ensuring `DisownLatch()` occurs earlier—and on the test infrastructure, including the handling of injection points. The discussion evolved around refining the test harness and the main fix, with the proposer submitting new patches to incorporate the review feedback.

This thread discusses the implementation of 'REPACK CONCURRENTLY', particularly focusing on the use of database-specific snapshots within the logical decoding mechanism. Initial concerns were raised about a plugin's declaration of not using shared catalogs, which led to a broader discussion about potential indirect breakages. The proposer identified a critical issue where the snapshot builder's transaction processing could incorrectly consider committed transactions as running when using database-specific snapshots, leading to lost data effects. A reviewer provided a clear method to reproduce this WAL ordering problem. Further architectural concerns were raised by another commenter regarding the fundamental mismatch between database-specific snapshots and the cluster-wide design of logical decoding, citing inefficiencies and limitations, such as incompatibility with standby servers. Due to these significant architectural challenges and the limited time before beta 1, a core developer decided to revert the database-specific snapshot aspect of 'REPACK CONCURRENTLY' for the current release (PostgreSQL 19), with the intention to revisit and redesign the feature for a future release (PostgreSQL 20).

This thread proposes a new `ON_CONFLICT TABLE` clause for the `COPY FROM` command, enabling the redirection of duplicate rows to a specified error table instead of aborting the entire load. The proposer outlined an initial implementation using a fixed four-column structure for the conflict table and leveraging `INSERT ON CONFLICT` mechanisms. Reviewers identified several critical issues across multiple patch versions, including null pointer dereferences, data loss scenarios, crashes with partitioned tables and repeatable reads, and incorrect behavior in binary mode. Concerns were also raised about the firing of triggers on the `CONFLICT_TABLE` and the handling of exclusion constraints. The proposer refactored the implementation to use exported `ExecInsert` functionality for better integration with the executor. While many issues have been addressed incrementally through v1 to v3 patches, ongoing discussions persist regarding relation lifecycle management, trigger behavior, and clear documentation of exclusion constraint interactions.

This thread discusses a patch designed to add a guard against potential NULL pointer dereferences that could occur if `pg_newlocale_from_collation(DEFAULT_COLLATION_OID)` is called from `_PG_init()` when the default locale is uninitialized. The proposer notes that while this specific scenario might not be currently reachable, the patch serves as a robust defense against similar issues in the future, particularly for extensions. The proposer also indicated plans to commit and backport the patch through PostgreSQL 17, with a slightly different version for the 17 release. A reviewer has approved the patch, offering only a minor suggestion for improving a comment in the PG 17-specific patch for greater clarity.

This thread investigates a deadlock encountered in the startup process, where it indefinitely waits for an auxiliary process (like the checkpointer) to acknowledge a ProcSignalBarrier. Initially, a reporter hypothesized the issue was due to signals being sent before the auxiliary process registered its handlers. However, a reviewer clarified that signals are blocked during child process startup, preventing this specific race. The reviewer then identified a different, more subtle race condition: EmitProcSignalBarrier() might skip signaling a process if its PID is not yet set in the shared memory slot, even if its barrier generation count is already initialized. This causes the waiting process to deadlock. Another reviewer confirmed this scenario with a test case and reproduced buildfarm failures. A patch was provided to address this race condition, which was successfully tested and confirmed to resolve the issue. The discussion concluded with the patch being committed and backported to versions 15 and newer, as the vulnerability, while more exposed by recent changes, existed in earlier versions with other operations like DROP DATABASE.

The thread addresses a critical bug in PostgreSQL's logical replication, specifically with ALTER SUBSCRIPTION ... SERVER or ALTER SUBSCRIPTION ... CONNECTION commands. The proposer identified that these commands fail if the foreign server associated with the original subscription becomes unreachable or its user mapping is dropped, preventing recovery. The root cause was GetSubscription attempting to retrieve connection information from the broken server even when it wasn't strictly necessary for the alteration. Initial patches focused on lazy loading of connection info. A reviewer proposed a refactored approach introducing a conninfo_needed parameter, which was adopted. The discussion evolved to also cover DROP SUBSCRIPTION failures under similar conditions, leading to a multi-patch series that carefully manages connection string construction and cleanup. The latest versions of the patch use subtransactions and refined logic to handle cases where publisher connection is impossible during drop operations gracefully. Reviewers and the proposer are currently discussing the complexity, error messages, and further code organization.

The thread begins with a proposer reporting a null pointer dereference in PostgreSQL 19 when using VIEWS, FOR PORTION OF, and INSTEAD OF triggers. The initial proposal suggests a parse-time check to forbid these features together. A reviewer immediately criticizes this approach, arguing that checks related to FDWs, volatile functions, and opclasses should occur in later execution phases because relation properties can change. Commenter 1 then takes over, noting the bug was known and suggesting a fix where INSTEAD OF triggers cause `FOR PORTION OF` to skip temporal leftover insertion. Commenter 2 contributes by proposing methods for handling volatile function and FDW checks within the planner/executor, specifically in `ExecInitModifyTable` and `CheckValidResultRel`. The discussion highlights that the original parse-time check proposal is flawed. The thread concludes with Commenter 1 adopting Commenter 2's suggestions and announcing that further development and CommitFest tracking for the refined patches will continue in a new, dedicated thread.

This thread discusses a patch aimed at preventing repeated `RECOVERY_CONFLICT_BUFFERPIN_DEADLOCK` signals during standby buffer pin waits. The proposer observed that when `deadlock_timeout` fires in `ResolveRecoveryConflictWithBufferPin()`, the function repeatedly sends the deadlock-check signal without waiting, similar to a previously fixed issue in the lock-conflict path. The proposed solution involves resetting the `got_standby_deadlock_timeout` flag and calling `ProcWaitForSignal()` after the signal, allowing the startup process to wait for `UnpinBuffer()` instead of looping. Reviewer 1 and reviewer 2 generally approved the patch, classifying it as an improvement rather than a bug fix, suggesting it target the v20 release. Reviewer 1 also suggested a minor initialization for symmetry, which the proposer incorporated into a v2 patch, confirming its performance benefit by reducing signal broadcasts during testing. However, a commenter later questioned the classification as an 'improvement,' citing another report where a similar issue was considered a bug dating back to an earlier PostgreSQL version.

This thread addresses a critical bug in the `COPY FROM ON_ERROR SET_NULL` command. The proposer identified that when a partial column list was used, particularly targeting higher-numbered columns, the system would incorrectly handle `NOT NULL` constraints on domain types. This led to an out-of-bounds read in `copyfromparse.c`, silently inserting `NULL` values into columns that should have enforced a `NOT NULL` constraint. The proposed solution involved correctly allocating the `domain_with_constraint[]` array using `num_phys_attrs` and indexing it with `attnum - 1`, ensuring consistency with other per-column arrays and proper constraint checking. A new test case was also included to cover the specific scenario. The fix was reviewed positively by multiple participants, with one reviewer noting they had independently found the same bug and developed a similar fix. The patch was subsequently committed.

The proposer initiated a thread announcing OpenSSL 4.0.0 release and the need to adapt PostgreSQL. The initial patch addressed compilation warnings arising from const changes in OpenSSL 4.0.0 APIs, ensuring libpq and sslinfo build without warnings across OpenSSL 1.1.1 to 4.0.0 and LibreSSL. Commenter 1 inquired about back-patching and compatibility with older OpenSSL versions. The proposer confirmed the need for back-patching and discussed the implications for older PostgreSQL branches (v14-master), initially suggesting to limit back-patching on v14 due to its older OpenSSL support. Commenter 2 tested the patch and found an issue with SSL tests failing due to OpenSSL 4.0 changing "ssl alert" to "tls alert" in error messages, which the proposer indicated might have been fixed in a later patchset. A core developer then weighed in, recommending back-patching to all branches, including v14, after the next minor releases, given that v14 still has two scheduled releases, allowing time to address any potential issues. The proposer accepted this plan and committed to preparing rebased patches for all branches.

This thread discusses adding tab completion support in psql for the `FOR PORTION OF` clause, which is used in `UPDATE` and `DELETE` statements with temporal tables. The proposer submitted an initial patch including the necessary changes and tests. A reviewer identified an issue where one of the completion rules did not function correctly during testing. Subsequently, the reviewer committed the patch to the codebase, but with the problematic rule removed to ensure the core functionality worked as intended. The proposer acknowledged the commit, expressed gratitude, and indicated plans to further explore and implement additional completion scenarios in the future.

The thread focuses on the review of the first draft of the PostgreSQL 19 release notes. The proposer shared the initial draft and sought feedback from the community. Discussions covered various aspects, including the precise wording for new features (e.g., clarifying CPU instruction usage), ensuring that all significant changes and new hooks were appropriately listed, and establishing clear criteria for what constitutes a relevant entry in the release notes for a general audience. Several participants offered specific suggestions for additions, removals, or rephrasing, and the proposer was actively incorporating these changes and explaining the rationale behind their decisions. The process aimed at refining the release notes to be comprehensive and accurate.

This thread proposes to extend the `EXCEPT` clause functionality to `TABLES IN SCHEMA` publications, similar to its existing use with `FOR ALL TABLES`. The goal is to provide users with a convenient way to exclude specific tables from schema-level publications without resorting to explicit `FOR TABLE` lists, which require manual updates. The proposer outlined a syntax for `CREATE`, `ALTER ADD`, and `ALTER SET` publication commands. Key rules include schema-qualification for excluded tables and ensuring they belong to the published schema. Early discussions focused on the syntax, particularly regarding 'mixed style' `EXCEPT` clauses (applying to multiple schemas in a single command). The proposer initially allowed this for convenience but later revised the approach to restrict `EXCEPT` to its adjacent schema clause to reduce complexity and confusion. The proposed changes are delivered in a series of three patches addressing different command types and related cleanup. Reviewers have provided detailed feedback on documentation, code logic, error messages, and `pg_dump` integration, to which the proposer has been responsive, providing updated patch versions.

The proposer identified a bug in pg_rewind where a rewound standby node can take an unacceptably long time to reach a consistent state if the new primary is idle. This occurs because pg_rewind sets the minRecoveryPoint using pg_current_wal_insert_lsn(), which can point just past a WAL page header when the primary is idle. Consequently, the standby waits indefinitely for a new WAL record to be written by the primary to advance its lastReplayedEndRecPtr past this minRecoveryPoint. The proposer suggested using GetXLogInsertEndRecPtr() instead, or adjusting the minRecoveryPoint if it's just after a WAL page header. A reviewer reproduced the bug and confirmed the diagnosis, agreeing that fixing the producer (pg_rewind) by using GetXLogInsertEndRecPtr() is the cleaner solution to maintain consistency across how minRecoveryPoint is set and compared. The reviewer also suggested additional documentation and auditing for a defense-in-depth approach, and offered to provide a TAP test, emphasizing the liveness bug's importance for back-patching.

The proposer announced the imminent shutdown of Cirrus CI on June 1, 2026, which is used by cfbot and individual developers, necessitating an urgent replacement. The proposer outlined seven key considerations for a new CI system, including self-hosting, open-source nature, speed, multi-OS support, personal repository integration, and free access. Commenters largely agreed on the importance of enabling CI on personal repositories and the desirability of self-hosting and open-source solutions. There was also discussion about optimizing CI resource usage, particularly for small or inactive patches, while preserving the value of initial runs. Towards the deadline, one developer provided an initial GitHub Actions YAML file as a temporary solution to ensure CI continuity, acknowledging it's not the long-term goal. Another developer then offered to take over and refine this patch.

This thread discusses the accuracy and reporting of TSC (Timestamp Counter) frequency, particularly in virtualized environments where CPUID 0x15/0x16 might report incorrect frequencies. A fix was committed early in the thread to avoid trusting CPUID 0x15/0x16 under certain hypervisors. The discussion then evolved to enhance `pg_test_timing` to warn users if the calibrated TSC frequency deviates significantly (e.g., >10%) from the frequency in use, advising to switch to `timing_clock_source=system` or report a bug, and to return an error code for CI/buildfarm failures. Reviewers contributed with suggestions for refining the debug information and addressing potential unsafe calls to calibration functions. A Coverity warning for a potential divide-by-zero issue in `output()` was also identified and resolved by adding a check. The proposer provided several patch iterations incorporating these improvements, and a committer eventually pushed the consolidated patch.

The thread addresses inconsistencies in PostgreSQL error messages, specifically focusing on DETAIL messages that do not end with a period or have incorrect capitalization, violating the project's error message style guide. The proposer submitted a patch to correct these issues. Several iterations of the patch were made based on feedback from reviewers. Discussions involved whether to add periods to DETAIL messages ending with substituted values (e.g., %s or %d), with the proposer deciding against it to avoid ambiguity. A key point of contention was whether simply adding a period to a non-sentence DETAIL message made it compliant or potentially more confusing. The latest patch version (v5) removed periods from non-sentence messages and those with uncontrolled initial capitalization. The thread has since gone quiet, and the proposer has pinged the list for further guidance to move the patch forward.

The thread discusses a proposal to increase the minimum supported version for `psql`, `pg_dump`, `pg_dumpall`, and `pg_upgrade` to PostgreSQL v10 for the upcoming v20 release. The proposer highlighted the burden of supporting older versions (currently v9.2) and provided a patch. Reviewers generally agreed with the proposal, citing benefits like shorter buildfarm runs. Feedback included requests to separate the patch into logical changes and formatting updates, and discussions arose about `pg_restore`'s ability to read older archive formats and the need for documentation on multi-hop upgrades. The proposer provided updated patches addressing some of the feedback. There was a consensus that this change should occur approximately every five years. The buildfarm maintainer confirmed that buildfarm changes were being pushed in anticipation of this update, indicating a decision has been made to proceed.

The thread highlights an issue in the PostgreSQL documentation for CREATE PUBLICATION and ALTER PUBLICATION, where some parameters listed in the command synopses (e.g., column_name, table_name, schema_name) are not adequately defined or even mentioned elsewhere in the respective documentation pages. The proposer argues that this inconsistency makes the documentation ad-hoc and potentially confusing for users. A small patch was submitted to address these omissions by adding comprehensive descriptions for the missing parameters and ensuring consistency across both command pages. Additionally, the patch includes a fix for missing <varlistentry> "id" attributes on the ALTER PUBLICATION page. The patch has been awaiting review feedback for several weeks.

This thread discusses an optimization for the `is_table_publication` and `is_schema_publication` functions in logical replication. The proposer identified that publications using 'FOR TABLE', 'FOR TABLES IN SCHEMA', and 'FOR ALL TABLES' clauses are mutually exclusive. The initial patch (v1) aimed to simplify and improve efficiency by adding a quick `return false` if `puballtables` is true, thereby avoiding unnecessary catalog scans. Reviewer 1 questioned the completeness of these checks, particularly for `is_schema_publication` and `puballsequences`. Reviewer 2 then pointed out that 'FOR ALL SEQUENCES' and 'FOR TABLES IN SCHEMA' are also mutually exclusive. The proposer acknowledged this and submitted patch v2, which incorporated checks for `puballsequences` into the early exit logic for both functions. Reviewer 2 later provided a detailed analysis, confirming that the optimization, while primarily benefiting non-erroneous scenarios, is a valuable addition. The proposer is now requesting guidance on moving the patch forward.

The thread initially explored a perceived misuse of the `_()` gettext macro. The proposer questioned its application with only a quoted format string. A reviewer clarified that this usage is intentional and necessary to allow translators control over quoting styles and other punctuation within localized messages. This clarification prompted the proposer to investigate the `GetPublicationsStr` function, which builds comma-separated lists, and found it lacked proper translation support for error messages. The proposer then submitted a patch to address this. After an initial iteration, a v2 patch was proposed. Reviewer 1 suggested a revised approach to include commas directly within the translated string to better accommodate linguistic variations. The proposer agreed with this, also proposing further code simplification regarding list iteration. The subsequent discussion briefly considered the stylistic choice of leading vs. trailing commas in translated elements, with both parties acknowledging it as minor. The proposer is now seeking to advance the patch.

This thread centers on the development and review of Row Pattern Recognition (RPR) functionality, primarily focused on a substantial v47 patch set and subsequent incremental updates. The initial message from the proposer outlined design considerations for FIRST/LAST navigation within RPR, emphasizing its interaction with the NFA engine and dependencies on `match_start`. The discussion quickly evolved into an active patch review cycle. The proposer submitted multiple sets of patches, addressing items such as unifying DEFINE walkers, rejecting volatile callees, improving regression tests for empty-match paths, refining DEFINE qualifier checks, and adhering to specific coding style guidelines (e.g., trailing commas, `ereport()` parentheses). Reviewer 1 provided critical feedback, including a detailed analysis of the SQL standard to prohibit RPR in recursive CTEs and offered enhancements for the `README.rpr` documentation. The proposer diligently incorporated this feedback, updating patches to enforce the recursive query prohibition and refine documentation. Reviewer 1 also provided context on the extensive scope of the RPR feature and its future development trajectory, including planned features like MEASURES.

The proposer introduced a patch to enhance pg_stat_all_tables by adding new fields to track tables skipped during autovacuum and autoanalyze due to lock acquisition failures. This aims to provide users with more direct insight into these events, which are currently only visible in server logs. The discussion involved several rounds of review and refinement. Key points addressed include improving the expand_vacuum_rel() logic, updating isolation tests, clarifying naming conventions, and, critically, resolving a race condition where concurrently dropped tables could lead to orphaned entries in the statistics. A solution mirroring pgstat_init_function_usage() for handling such entries has been implemented and refined across multiple patch versions.

This thread discusses a patch aimed at improving the accuracy of WAL segment creation counts reported in `log_checkpoints` output. The proposer identified that the existing count is incomplete, only reflecting segments preallocated, and not those created by other processes. The proposed solution involves a new shared-memory atomic counter (`walSegmentsCreated`) that is incremented whenever a WAL segment is created, regardless of the source. The `ckpt_segs_added` metric would then accurately reflect all newly created segments since the last checkpoint. Initial feedback requested the addition of tests, which the proposer provided. Subsequent comments focused on minor textual and indentation fixes, and a question regarding potential integer overflow for the `ckpt_segs_added` field. Later, reviewer 1 suggested extending the functionality by exposing this counter in `pg_stat_checkpointer` for monitoring, raised questions about making `walSegsCreatedLastCheckpoint` atomic, clarified the integer type's overflow threshold, and proposed additional testing with `wal_level=minimal`.

The thread discusses a patch to enable function scan pushdown for Foreign Data Wrappers (FDW), specifically for PostgreSQL FDW. The initial patch was returned with feedback due to unresolved issues with `rte->functions` and an unfinished design. The proposer submitted an updated patch (v3), disallowing pushdown for functions returning complex types or with parameters. A reviewer tested v3 and v4, noting that pushdown was not observed in their tests due to planner cost estimation favoring local joins. The proposer explained the cost model, emphasizing that remote joins must be cheaper. Subsequent patch versions (v5, v6) addressed issues with deparsing whole-row variables for function RTEs and handling `postgresBeginForeignScan` for function RTEs. The discussion also involved restoring per-function metadata. The latest discussions focus on refining whole-row variable deparsing for nullable outer sides and correctly handling `fdw_private` data for base restrict infos, suggesting further complexity in the patch.

The proposer identified a bug in `pg_rewind` where a target database could appear to start normally after a rewind operation but would actually be in an incomplete recovery state, leading to errors only upon user queries. This occurs when WAL segments are missing on the standby, preventing `minRecoveryPoint` from being reached. The initial patch aimed to relax recovery conditions to catch this earlier. A second, independent bug was later reported where `pg_rewind` could incorrectly set `minRecoveryPoint` beyond the available WAL, potentially due to the order of retrieving file lists and querying LSNs, which could add new segment files in between. This second issue, exposed by the first patch, is addressed by a separate patch (`0002`) that captures the expected `minRecoveryPoint` earlier to ensure consistency.

A bug was reported where `pg_dump --statistics-only` fails with an "could not find index attname" error when a table has multiple indexes, including an index on an expression. The proposer provided a simple patch, explaining that `pg_dump` can incorrectly use attribute names from a previously processed index on an expression for a subsequent regular index. A reviewer confirmed the underlying bug (incorrect inheritance of `indAttNames`), but couldn't reproduce the user-facing error on a vanilla PostgreSQL system. The proposer's latest reply clarified that the issue arises in their specific fork because it generates `pg_statistics` entries for all indexes, unlike vanilla PostgreSQL which only does so for expression indexes. This explains why the bug is not easily reproducible on vanilla, but the underlying issue of `pg_dump` misusing `indAttNames` after processing an expression index remains pertinent to the patch.

This thread discusses several patches for SQL Property Graph Queries (SQL/PGQ), primarily focusing on the correct handling of element variable references within `GRAPH_TABLE` clauses. The proposer submitted patches (0001 and 0002) to ensure that non-local cross-references between element variables in graph patterns are properly rejected, and to correctly resolve property references by prioritizing them over lateral table references when names conflict. A reviewer provided extensive testing, confirming that the patches functioned as expected across various complex scenarios. Discussions also clarified `GRAPH_TABLE`'s implicit `LATERAL` semantics as per the SQL standard. Both patches were ultimately committed. Later in the thread, a new commenter reported an internal error related to `GRAPH_TABLE` referencing outer tables, which was subsequently identified as being resolvable by a patch from a related, ongoing discussion.

The thread discusses an inconsistency in PostgreSQL's `synchronized_standby_slots` where it requires all listed slots to catch up, even when `synchronous_standby_names` is configured for quorum (ANY M of N) replication. This leads to logical decoding blocking if a non-essential standby goes down. The proposer introduced a patch to extend `synchronized_standby_slots` with quorum-aware syntax (ANY M of N) and later proposed adding priority-based syntax (FIRST N). The discussion evolved to splitting the work into three patches: first, refactoring the synchronous replication parser to better distinguish syntax forms; second, implementing `ANY N` semantics; and third, implementing `FIRST N` semantics. Reviewers provided feedback, including identifying a bug where duplicate entries in priority configuration are not filtered, which the proposer has committed to addressing.

This thread announces and provides an update on the 2026 PostgreSQL hacker mentoring program. The proposer, who runs the program, initiated a call for applications for potential mentees, detailing the program's success and target audience (active mailing list developers interested in committing significant time to hacking). The initial message included a signup form and a deadline for applications. A follow-up message reported that 23 applications were received, and 7 individuals were successfully matched with committers as mentors. The proposer expressed gratitude to the volunteering committers.

This thread addresses a bug in PostgreSQL's streaming replication where cascading standbys fail to reconnect after falling back to archive recovery if their upstream is an archive-only standby. The core issue is that the cascading standby requests a WAL streaming position (start of the next segment) that is ahead of the upstream's reported WAL flush position (inside the current segment), leading to connection failures. Initially, the proposer attributed this to `RequestXLogStreaming` truncating the `recptr` upwards. However, a reviewer clarified that the actual cause is archive recovery's segment granularity: after both nodes replay a segment, the cascade's next read position advances to the start of the next segment, while the upstream's reported position remains within the previously replayed segment. The proposed fix involves the `walreceiver` polling and waiting for the upstream to catch up within a one-segment boundary, incorporating a `wal_receiver_timeout` check and resetting the catchup state. While polling is acknowledged as not ideal, it is considered a reasonable and backpatchable solution for the bug.

This thread addresses a race condition in PostgreSQL's logical replication, specifically concerning the update of a replication slot's minimum LSN (Log Sequence Number). The race condition could lead to premature WAL segment removal and subsequent invalidation of newly created replication slots. The scenario arises when a new slot's `restart_lsn` is being initialized concurrently with other backends computing the global minimum LSN, potentially causing an older LSN to be recorded globally before the new slot's LSN is fully established. The proposer identified this issue and provided a patch that introduces an exclusive `ReplicationSlotControlLock` to protect updates to `slot.restart_lsn` during WAL reservation and also to `XLogSetReplicationSlotMinimumLSN()`. This synchronization mechanism ensures that updates and computations of the minimum LSN are serialized, thereby preventing the race. A reviewer confirmed the fix's correctness and clarified the safety of a similar code path in `copy_replication_slot()`. The patch has undergone successful testing.

This thread discusses improvements and bug fixes related to the `WAIT FOR LSN` functionality, particularly concerning how replay waiters are woken up and memory barrier semantics. Initial patches addressed a misplaced wake-up call and memory barriers in `GetWalRcvWriteRecPtr()`. The discussion involved ensuring proper handling of `writtenUpto` with atomic operations and robust testing for various scenarios, including off-by-one errors and timeline boundaries. The proposer assembled a patchset, which underwent several revisions to incorporate feedback, improve test coverage, and address a newly discovered test failure in `wait_for_catchup()`. The thread concludes with the proposer reviewing a fix for this test failure and the initial patchset being committed.

The proposer initiated a thread to address the difficulty in debugging test failures due to unhelpful output from Meson, both in CI and locally. They submitted patches to improve test output by including relevant snippets from `regression.diffs` and clearer error messages. The initial patches were committed. However, reviewer 1 immediately raised concerns that the new diff output often exceeded terminal width, becoming garbled and obscuring important test summaries. They suggested limiting the output further or making it conditional. The committer then proposed an adjustment to make the diff output dependent on an environment variable, adding this to the CI configuration. Commenter 2 identified another problem: the new log processing removed crucial timing information for failed tests. The proposer has since submitted a new patch aiming to resolve the issues raised by reviewer 1, acknowledging that the timing information issue is a separate concern related to the use of `command_ok`.

This thread proposes a new feature, `pg_stat_io_histogram`, to track and display I/O latency profiles, aiming to help users identify I/O outliers quickly. The initial patch focused on avoiding overhead with fast bucket calculation. Much of the subsequent discussion revolved around optimizing memory usage, particularly in each backend and in shared memory, as early versions significantly increased `pgStatLocal` and `PendingIOStats` sizes. Reviewers raised concerns about wasting memory for unused statistics. The proposer developed several patch versions (v7, v9a, v9b, v10) exploring different memory optimization strategies, including dynamically allocating memory and using indirect offsets to reduce the footprint. Performance testing indicated negligible CPU impact. The debate also included histogram range and bucket width. The latest patch, v10, aims to address memory concerns using indirect offsets and dynamic shared memory allocation on startup, making the shared memory footprint acceptable.

This thread discusses a bug where the deadlock detection mechanism fails to activate on a hot standby replica, specifically when a deadlock occurs between startup and backend processes during XLOG_HEAP2_PRUNE_* message processing. This can lead to significant recovery delays, especially if `max_standby_streaming_delay` is disabled. The proposer identified that the root cause lies in `timeout.c` and `ResolveRecoveryConflictWithBufferPin`, where the `SIGALRM` handler can be triggered "spontaneously" due to an optimization in `setitimer` calls, prematurely waking up the process before an actual timeout. If `deadlock_timeout` is larger than `log_startup_progress_interval`, the deadlock detector may never trigger. The proposer submitted a patch aimed at ignoring these spontaneous `SIGALRM` signals. A reviewer then provided detailed feedback on the patch, suggesting improvements to include ordering, clarifying comments regarding `ProcWaitForSignal` wake-ups, explicitly checking the waiter state, and simplifying the control flow within the waiting loop.

This thread proposes and reviews a new function, `pg_get_publication_ddl`, designed to generate the DDL for PostgreSQL publication objects. The proposer initially submitted a patch (v1) and sought feedback, particularly on the implications of viewing publication details without explicit 'view' privileges and how to handle default values. Reviewers provided extensive feedback on v1, pointing out numerous typos, potential information leaks due to missing `ONLY` clauses, incorrect schema prefix handling, and suggesting various code and documentation improvements. The proposer then submitted v2, incorporating a new structure, adding `pretty` and `owner` options, improving string management, using cache instead of shared locks, addressing grammar, and enhancing test coverage, including support for the `EXCEPT` clause. Reviewers are now actively providing detailed feedback on the v2 patch, focusing on documentation clarity, parameter naming, and minor code style adjustments to further refine the proposal.

This thread discusses a patch to add `WHERE` clause support to `REFRESH MATERIALIZED VIEW`, enabling partial refreshes to improve performance by targeting only changed data. The proposer initially implemented a 'Prune + Upsert' strategy for non-concurrent refreshes. An early commenter highlighted a real-world need for this feature. Reviewers identified a bug in unique index handling and raised concerns about consistency gaps in the non-concurrent mode. The proposer considered using transaction-level advisory locks to address concurrency but abandoned it due to scalability issues. The revised approach for non-concurrent refreshes now uses `SELECT ... FOR UPDATE` followed by a single CTE for upsert/delete. Discussion also touched upon whether the `CONCURRENTLY` keyword's semantics might become inverted with a `WHERE` clause, and the need for clear documentation on concurrency guarantees for this feature.

The thread explores the implementation of optimizer statistics for joins and foreign keys, aiming to improve cardinality estimates. The initial discussion introduced the concept of collecting statistics for referenced rows and attributes in joined tables. A proposer presented a proof-of-concept and later, a more refined v1 patch, incorporating an index-based join sampling algorithm, a new catalog design to support N-way joins, and a full `CREATE STATISTICS` syntax. Benchmarking results using the Join Order Benchmark (JOB) indicated performance improvements with the new statistics. Subsequent patch versions (v2-v7) primarily focused on addressing continuous integration (CI) failures, minor error handling, and rebase issues. The proposer continues to seek feedback on the overall design and feasibility of the approach, rather than minor code polish.

This thread originated from the proposer identifying a typo in `src/include/port/atomics/arch-x86.h` (`__i568__`, `__i668__` instead of `__i586__`, `__i686__`). Initial discussions questioned whether to fix the typo or remove the code entirely, given its long-standing presence without issues. Investigation revealed inconsistent compiler behavior for 32-bit builds across different Linux distributions regarding these macros. Ultimately, the consensus shifted away from fixing the typo to removing the problematic 32-bit specific code altogether, as performance work for 32-bit builds was deemed a low priority. The committer agreed to apply the removal patch, with a separate fix for 64-bit MSVC detection to be addressed later.

This thread discusses a proposed patch to expose the last checkpoint's duration and timestamp in pg_stat_checkpointer. The proposer believes this addition will significantly aid external monitoring tools in detecting sudden performance anomalies, such as unusually long or frequent checkpoints, which are hard to infer from existing cumulative statistics. Commenter 1 initially expressed skepticism about the utility of single-value gauges but provided detailed feedback, including a suggestion to split the patch and a request for concrete examples of how monitoring charts would improve. The proposer has since updated the patch, provided test observations, and offered detailed explanations on how the new metrics would enable clearer detection of checkpoint issues. Commenter 2 suggested looking at pgbadger for monitoring examples. The proposer is keen to rebase and continue development based on further feedback.

This extensive thread focuses on optimizing `LISTEN/NOTIFY` functionality. The proposer introduced a new design for tracking `LISTEN` state using hash tables at three levels: per-transaction pending changes, per-backend committed state cache, and cluster-wide shared state. This aimed to reduce shared dshash operations by performing more work locally and deduplicating actions. Significant discussion revolved around the terminology and the handling of 'laggard' backends not interested in specific notifications, to avoid a 'thundering herd' problem. A reviewer proposed a revised patch (v35) incorporating cosmetic changes and bug fixes, including restoring the previous behavior for laggard backends. The latest messages indicate that v35 was committed, and a follow-up comment identified an inconsistency in the `async-notify.spec` test related to `ChannelHashAddListener()`, which was eliminated in an earlier patch version.

This thread focuses on the development of a new function, `pg_get_subscription_ddl()`, designed to retrieve the full DDL statement for a PostgreSQL subscription. The function aims to generate the `CREATE SUBSCRIPTION` statement, including all its options, given a subscription name. The discussion involved numerous review cycles and patch revisions (up to v8). Key topics debated included whether the function should always emit all options, even default values, or a more compact DDL. Security concerns regarding passwords in connection strings were addressed by limiting function access to privileged roles. There was also discussion on how to handle `create_slot` and `copy_data` options, which are not directly stored in the catalog, and whether generated options should follow documentation order. The latest messages indicate the patch has been thoroughly reviewed and tested, with its functionality confirmed, and is now ready for the committer's final approval.

This thread concerns an obsolete comment in the `AtEOXact_Inval()` function, which inaccurately stated that the function "should be called as the last step in processing a transaction." The proposer identified this discrepancy, as several other transaction finalization steps now occur after `AtEOXact_Inval()`. Reviewer 1 confirmed the comment's historical origin and its current inaccuracy. The proposed patch to remove the comment was met with agreement.

The thread began with a proposer highlighting a misleading error message and duplicated code related to `T_CreateStatsStmt` within `ProcessUtilitySlow`. The core aim was to refactor the code by moving parse analysis into `CreateStatistics()`, reducing redundant `RangeVar` lookups, and enhancing robustness against race conditions. Discussions involved various refinements, including simplifying related functions and ensuring proper handling of relation objects. A reviewer raised a point about a potential regression in error reporting context, which was noted. A significant discussion also centered on how the proposed changes would interact with hypothetical future support for extended statistics spanning multiple relations, a design consideration that remains open. The latest patches aim to address the code structure and race conditions while awaiting further input on the multi-relation aspect.

This thread initially proposed enhancing `postgres_fdw` with new options to import statistics from a remote server, aiming to reduce the need for expensive local sampling. The `fetch_stats` option (defaulting to true) would attempt to retrieve remote relation and attribute statistics. A separate `remote_analyze` option (defaulting to false) was proposed to trigger a remote `ANALYZE` if attribute statistics weren't initially found. The `fetch_stats` functionality was reviewed, deemed committable, and subsequently pushed. Following this, a reviewer identified a potential buffer overflow issue with `strncpy` calls related to attribute names, flagged by Coverity, suggesting `strlcpy` or dynamic allocation. The proposer provided two solutions: one using `pg_mbcliplen+memcpy` and another dynamically allocating and freeing string buffers for attribute names. The dynamic allocation approach was preferred by a reviewer, who further refined the patch by removing unnecessary NULL checks. This refined patch addressing the `strncpy` issue was then also committed, while the `remote_analyze` feature was deferred to a new discussion.

This thread addresses a long-standing bug in postgres_fdw where DELETE/UPDATE operations on partitioned foreign tables could corrupt data by incorrectly modifying or deleting rows not matching the WHERE clause. The proposer revived an old patch to restrict these operations, but commenter 1 demonstrated its inadequacy with a concrete example. Various solutions were discussed, including disallowing modifications on such tables entirely or using WHERE CURRENT OF with cursors, though the latter raised performance concerns. Commenter 3 introduced a new approach focusing on extending the copy slot/tuple machinery to handle remote OID attributes and pass them to the FDW engine for correct UPDATE/DELETE queries. A patch set implementing this more comprehensive solution has been submitted to Commitfest.

The thread discusses a long-standing issue of orphaned object dependencies, proposing a solution that involves acquiring heavyweight locks on referenced objects during DDL operations. The core idea is to prevent race conditions during concurrent DROP operations. Early in the discussion, a reviewer expressed concerns about the "subtle timing" of these locks and potential security implications, specifically distinguishing between cases where permissions are checked before (P1) or after (P2) a lock is acquired. The proposer then focused on identifying and addressing P1 cases, which are deemed more critical from a security standpoint. A new patch (v20/v21) has been submitted, which includes three sub-patches: one for general lock acquisition, one for ensuring locks are taken before permission checks in P1 cases, and an assertion-based mechanism to detect future regressions in this area. A commenter also noted customer interest in this fix. Discussion continues around the scope and safety of the proposed assertion mechanism, with the proposer defending its design and efficacy.

The proposer initiated a thread to add `amcheck` support for BRIN indexes, outlining a patch with index structure checks (meta page, revmap, regular pages) and consistency checks between heap and index. Early discussions revolved around how to handle operator identification for the 'all consistent check', especially for opclasses that lack an equality operator, with commenter 1 suggesting leveraging existing primitives and the proposer exploring user-defined operators or a catalog mapping. Reviewer 1 provided detailed feedback, proposing an optional operator argument, requiring tests for multi-column indexes, suggesting improvements to the `CheckIndexCheckXMin` function, and requesting documentation updates. The proposer subsequently updated the patch to incorporate some of these suggestions, making the operator list optional and relocating `indcheckxmin`. More recently, the proposer reiterated the idea of an opclass-to-operator mapping to simplify user experience. Reviewer 2 successfully applied and built the updated patch, performing basic validation tests and noting a necessary `ALTER EXTENSION amcheck UPDATE` for existing `amcheck` installations, which the proposer confirmed as expected behavior for upgrades.

This lengthy thread discusses and ultimately resolves a bug concerning superuser access to temporary tables of other sessions. Initially, PostgreSQL explicitly forbade such access for most operations, with `DROP` being a conscious exception. However, a specific commit later introduced a regression, allowing superusers to perform other operations like `SELECT` on another session's temporary table, particularly when empty. The proposer submitted a patch to restore the intended behavior, preventing erroneous access for operations other than `DROP`. The discussion involved considerations for backpatching, focusing on versions affected by the regression (PG17 onwards), and potential issues with older versions (PG14-16) where the bug manifested differently. After a brief delay due to the code freeze for minor releases, the committer pushed the fix, adapting tests for different versions. The original proposer also acknowledged a separate, related architectural issue concerning `relpersistence` that remains to be addressed.

This thread proposes adding a new flag, initially `--pipe-command` and later renamed to `--pip`, to `pg_dump` and `pg_restore` for use with the directory output format (`-Fd`). The feature aims to enable piping individual dump files to external commands, offering flexibility for custom compression, streaming to cloud storage, or transferring data via SSH, which is currently not possible with the directory format. The proposer introduced a `%f` specifier for dynamic file naming within the pipe command. A reviewer provided extensive feedback, suggesting a shorter flag name, improved error handling, more comprehensive testing, and considering `pg_dumpall` support. The proposer has since rebased the patch multiple times, incorporated many suggestions including renaming the flag to `--pip`, enhancing error handling, adding numerous tests for various scenarios and parallelism, and specifically addressing Windows compatibility. Support for `pg_dumpall` has been deferred for a future patch.

This thread addresses a critical bug in libpq related to processing buffered SSL/GSSAPI read bytes, particularly for records larger than 8KB when using the async API, which could lead to deadlocks or hangs. The proposer submitted a patch series aiming to fix GSSAPI-specific issues and ensure `pqReadData()` drains transport buffers. Initial patches sparked extensive architectural discussions regarding buffering strategies and the interaction with OpenSSL readahead. Reviewers provided significant feedback, identifying issues like layering violations and a bug where a buffer pointer (`conn->inEnd`) was not advanced after draining, potentially leading to data loss. A reproducer script was shared, demonstrating the bug's occurrence and the patch's effectiveness. The latest version (V3) has undergone testing, with a reviewer confirming its successful application, build, and operation without regressions during async libpq tests and large `COPY TO STDOUT` operations over SSL.

This thread discusses random `pg_upgrade` test failures on Windows buildfarm machines, specifically the `004_subscription` test, exhibiting a "File exists" error during schema restoration. The proposer suggests this is due to a `STATUS_DELETE_PENDING` issue on Windows, where `pgunlink()` succeeds but the file isn't immediately released, causing `mdcreate()` to fail. A potential fix involving `WaitForProcSignalBarrier` within `mdcreate()` for Windows-specific `STATUS_DELETE_PENDING` errors was proposed and a patch submitted. A reviewer raised concerns about adding more Windows-specific code and suggested alternative approaches or dedicated test modules for concurrent file operations. Subsequently, the discussion shifted to the critical problem that `pg_upgrade_output.d` logs, vital for debugging these failures, were not being collected by the buildfarm. The latest messages confirm that the buildfarm logging bug has been identified and fixed, allowing for proper diagnosis of future failures.

This thread discusses the implementation of Sequence Access Methods in PostgreSQL, allowing custom sequence generation. The proposer introduced several patch versions, with v11 being the first in the visible messages and v28/v29 later. A reviewer provided detailed feedback on v26, covering documentation clarity, header file ordering, handling of unlogged sequences, use of default constants, and macro design, to which the proposer largely responded. Another reviewer later rebased the patch set, offering comments on a snowflake sequence implementation and performance concerns related to function pointers. The proposer noted a lack of wider developer enthusiasm, leading to the patch being dropped from the commitfest, though he still supports the design. The latest exchanges include the second reviewer providing benchmark results for v29, indicating a slight performance improvement over the baseline, and suggestions for further optimization regarding cache lookups. The core idea is to enable extensible sequence generation, which is seen as crucial for distributed applications.

The thread discusses a patch to introduce a new configuration parameter, initially named `max_log_size`, to truncate long statements in PostgreSQL logs. The proposer submitted several iterations of the patch, addressing feedback regarding indentation, trailing whitespace, and making it session-wise configurable. Early reviews confirmed its functionality for basic statement logging. A committer raised several concerns, including the misleading parameter name (suggesting `log_statement_max_length`), issues with empty STATEMENT lines in logs, the applicability to replication commands, and the need to extend truncation to other logging contexts like `exec_parse_message`, `exec_bind_message`, `exec_execute_message`, and CONTEXT lines. The parameter name was changed to `log_statement_max_length`, the default value to -1, and `strlen()` calls were optimized. The proposer later extended the truncation logic to cover `exec_execute_message`, `exec_parse_message`, and `exec_bind_message`. A recent comment highlighted that statements with errors were still logged in full, suggesting a companion parameter like `log_statement_max_length_on_error`, which the committer suggested handling in a separate patch. The latest message is a rebase due to recent changes in `src/test/modules/test_misc/meson.build`.

This thread proposes a mechanism to bypass cursors in `postgres_fdw` to enable parallel query plans on the remote server, addressing a limitation where parallel plans fail due to cursor usage. The initial approach introduced a GUC `postgres_fdw.use_cursor` and used `PQsetChunkedRowsMode` in non-cursor mode. A challenge arose with simultaneous queries, leading to the development of a mechanism to store fetched data in a Tuplestore when a cursor switch occurs. The patch underwent significant refactoring based on reviewer feedback, including adding a Tuplestore to `PgFdwScanState`, renaming flags, and improving `postgresReScanForeignScan` logic. Discussions highlighted issues like unnecessary code, flag naming, `active_scan` pointer management, and `ExprContext` usage. The latest version of the patch split the changes into two, the first renaming `cursor_exists` to `scan_in_progress` and the second implementing the fetch mechanism, and introduced a new GUC `streaming_fetch`.

This thread discusses an improvement to PostgreSQL's statistics system, aiming to address inaccuracies in statistics after a crash recovery or failover. The core proposal is to key statistics by `relfilenode` instead of relation OID, which can change. Earlier ideas, such as storing OID to buffertag mapping, were dismissed due to recovery limitations. The main debate focuses on the design of the `PgStat_StatTabEntry` structure. Reviewer 1 suggested splitting it into table, index, and relfilenode specific fields from the outset to avoid complexity, particularly concerning partitioned tables and unnecessary data for autovacuum. The proposer, supported by reviewer 2, argues for an incremental approach, advocating for a unified structure initially and considering a split later, once WAL-replay-based stat population is implemented. The proposer believes the current patch (v16) adequately addresses technical concerns and is a necessary step that doesn't hinder future architectural changes, and is seeking a committer to drive it forward.

This thread proposes a new `PAGEFAULTS` option for `EXPLAIN (ANALYZE)` to report minor and major page fault counts during query planning and execution. The goal is to provide deeper insights into storage I/O activity beyond what `BUFFERS` currently offers, aiding in diagnosing slow queries. Early discussions covered platform limitations (Windows `getrusage()`) and the performance impact of per-node reporting. A key ongoing concern is the accuracy of `getrusage()` with asynchronous I/O methods, particularly bgworker-based AIO, which could lead to undercounting. The proposer adapted the patch to suppress output when `io_method=worker`. Reviewers have provided detailed feedback on output format, naming, documentation, and test coverage, leading to iterative patch revisions. The thread is still active, with a reviewer recently reiterating concerns about the interpretability of the reported I/O statistics.

The thread discusses a bug in PostgreSQL's `mdunlinkfiletag` function where it incorrectly unlinks segment 0 of the main fork instead of the specified fork and segment. This issue was identified as affecting PG16+ for forks and PG12+ for segments, potentially leading to incorrect file deletion during recovery. The proposer initially provided a patch to correct this by enabling the function to unlink the exact requested files. However, a reviewer suggested an alternative: instead of generalizing the function, restrict its scope. Given that its only known use case within the core system is for "tombstone" files, the reviewer proposed renaming `register_unlink_segment()` to `register_unlink_tombstone()` and removing the fork/segment arguments to clarify its limited purpose. This approach was adopted in a subsequent patch version. Later reviewers praised this direction, noting it clarifies intent and adds an `Assert()` for safety. The patch is now considered in good shape, with a minor comment suggestion agreed upon.

This thread concerns the implementation of the `PLAN` clause for `JSON_TABLE`, a feature from the SQL/JSON standard. The proposer initiated the work, adapting the clause to recent `JSON_TABLE` changes and correcting existing tests, noting that some code had to be reverted. An early comment supported the feature despite Oracle's non-adoption. Over several patch iterations, reviewers provided extensive feedback, highlighting issues such as missing documentation, a mixture of refactoring and new code, incomplete comments, and incorrect `IsA()` macro usage. Concerns were also raised about the default behavior of `JSON_BEHAVIOR_EMPTY` in deparsing versus `JSON_BEHAVIOR_EMPTY_ARRAY` in parsing, and the unnecessary emission of the `PLAN` clause during deparsing. The proposer has consistently addressed this feedback, re-partitioning the patch into distinct code, test, and documentation components for easier review.

This thread details the development of a feature to allow COPY FROM to save error information into a designated table rather than stopping or ignoring errors. The evolution of the patch, through multiple versions, shows a progression from direct memory manipulation to a more robust executor-based approach using ExecInsert(). The current design leverages a built-in composite type, copy_error_saving, for the error table schema, which simplifies validation. The feature introduces new syntax COPY FROM ... ON_ERROR TABLE, ERROR_TABLE err_tbl. Initial reviews focused on minor code style and the idea of auto-creating the error table. Later versions significantly refactored the implementation to integrate with the executor's ModifyTableState and ResultRelInfo nodes, which was praised for its cleanliness. However, subsequent reviews identified several critical issues in version 11, including premature closing of a relation leading to crashes, incorrect ordering of trigger handling, potential miscounting of errors when BEFORE INSERT triggers return NULL, missing null checks, and redundancy in permission checks. The proposer acknowledged some of these issues and proposed fixes, while further discussions on the clarity of error messages and documentation for trigger behavior are ongoing.