pgsql: plpython: Clean up PyModule_AddObject() uses

plpython: Clean up PyModule_AddObject() uses The comments "PyModule_AddObject does not add a refcount to the object, for some odd reason" seem distracting. Arguably, this behavior is expected, not odd. Also, the additional references created by the existing code are apparently not necessary. Bu

pgsql: plpython: Remove commented out code

plpython: Remove commented out code This code has been commented out since the first commit of plpython. It doesn't seem worth keeping. Reviewed-by: Chao Li Reviewed-by: Matheus Alcantara Reviewed-by: li carol Reviewed-by: Kirill Reshke Discussion: https://www.postgresql.org/message-id/f3133

pgsql: Remove some unnecessary code from multixact truncation

Remove some unnecessary code from multixact truncation With 64-bit multixact offsets, PerformMembersTruncation() doesn't need the starting offset anymore. The 'oldestOffset' value that TruncateMultiXact() calculates is no longer used for anything. Remove it, and the code to calculate it. 'oldestO

Re: pgsql: Enable Python Limited API for PL/Python on MSVC

This is failing on buildfarm member drongo: . AFAICT, this is the only buildfarm member that tests Python on Windows, so we have no additional results to compare with. It did pass on Cirrus CI. Andrew/Bryan, could

pgsql: pgindent fix for 8077649907d

pgindent fix for 8077649907d Per buildfarm member koel. Backpatch-through: 18 Branch -- REL_18_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a80811e592a3f6851e113fbdf5fe21e677391bb9 Modified Files -- src/backend/storage/aio/method_io_uring.c | 2 +- 1 file chan

pgsql: Add pg_clear_extended_stats()

Add pg_clear_extended_stats() This function is able to clear the data associated to an extended statistics object, making things so as the object looks as newly-created. The caller of this function needs the following arguments for the extended stats to clear: - The name of the relation. - The sc

pgsql: Add a new helper function wait_for_file() to Utils.pm.

Add a new helper function wait_for_file() to Utils.pm. wait_for_file() waits for the contents of a specified file, starting at an optional offset, to match a given regular expression. If no offset is provided, the entire file is checked. The function times out after $PostgreSQL::Test::Utils::timeo

pgsql: pg_recvlogical: Prevent flushed data from being re-sent.

pg_recvlogical: Prevent flushed data from being re-sent. Previously, when pg_recvlogical lost connection, reconnected, and restarted replication, data that had already been flushed could be streamed again. This happened because the replication start position used when restarting replication was ta

pgsql: Add test for pg_recvlogical reconnection behavior.

Add test for pg_recvlogical reconnection behavior. This commit adds a test to verify that data already received and flushed by pg_recvlogical is not streamed again even after the connection is lost, reestablished, and logical replication is restarted. Author: Mircea Cadariu Co-authored-by: Fujii

pgsql: pg_recvlogical: remove unnecessary OutputFsync() return value ch

pg_recvlogical: remove unnecessary OutputFsync() return value checks. Commit 1e2fddfa33d changed OutputFsync() so that it always returns true. However, pg_recvlogical.c still contained checks of its boolean return value, which are now redundant. This commit removes those checks and changes the ty

Re: pgsql: Enable Python Limited API for PL/Python on MSVC

On 1/15/2026 3:36 AM, Peter Eisentraut wrote: > This is failing on buildfarm member drongo: buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=drongo&br=master>. >  AFAICT, this is the only buildfarm member that tests Python on Windows, > so we have no additional results to compare with.  It did

pgsql: Add check for invalid offset at multixid truncation

Add check for invalid offset at multixid truncation If a multixid with zero offset is left behind after a crash, and that multixid later becomes the oldest multixid, truncation might try to look up its offset and read the zero value. In the worst case, we might incorrectly use the zero offset to t

pgsql: Wake up autovacuum launcher from postmaster when a worker exits

Wake up autovacuum launcher from postmaster when a worker exits When an autovacuum worker exits, the launcher needs to be notified with SIGUSR2, so that it can rebalance and possibly launch a new worker. The launcher must be notified only after the worker has finished ProcKill(), so that the worke

pgsql: Add check for invalid offset at multixid truncation

Add check for invalid offset at multixid truncation If a multixid with zero offset is left behind after a crash, and that multixid later becomes the oldest multixid, truncation might try to look up its offset and read the zero value. In the worst case, we might incorrectly use the zero offset to t

pgsql: Add check for invalid offset at multixid truncation

Add check for invalid offset at multixid truncation If a multixid with zero offset is left behind after a crash, and that multixid later becomes the oldest multixid, truncation might try to look up its offset and read the zero value. In the worst case, we might incorrectly use the zero offset to t

pgsql: aio: io_uring: Fix danger of completion getting reused before be

aio: io_uring: Fix danger of completion getting reused before being read We called io_uring_cqe_seen(..., cqe) before reading cqe->res. That allows the completion to be reused, which in turn could lead to cqe->res being overwritten. The window for that is very narrow and the likelihood of it happe

pgsql: aio: io_uring: Fix danger of completion getting reused before be

aio: io_uring: Fix danger of completion getting reused before being read We called io_uring_cqe_seen(..., cqe) before reading cqe->res. That allows the completion to be reused, which in turn could lead to cqe->res being overwritten. The window for that is very narrow and the likelihood of it happe

pgsql: Remove #include where not needed

Remove #include where not needed Liujinyang reported the one in binaryheap.c, I then found and analyzed the rest. For future patches, we require git archaelogical analysis before we accept patches of this nature. Co-authored-by: liujinyang <[email protected]> Co-authored-by: Álvaro Herrera Discu

pgsql: Add check for invalid offset at multixid truncation

Add check for invalid offset at multixid truncation If a multixid with zero offset is left behind after a crash, and that multixid later becomes the oldest multixid, truncation might try to look up its offset and read the zero value. In the worst case, we might incorrectly use the zero offset to t

pgsql: Add check for invalid offset at multixid truncation

Add check for invalid offset at multixid truncation If a multixid with zero offset is left behind after a crash, and that multixid later becomes the oldest multixid, truncation might try to look up its offset and read the zero value. In the worst case, we might incorrectly use the zero offset to t

pgsql: Add check for invalid offset at multixid truncation

Add check for invalid offset at multixid truncation If a multixid with zero offset is left behind after a crash, and that multixid later becomes the oldest multixid, truncation might try to look up its offset and read the zero value. In the worst case, we might incorrectly use the zero offset to t

pgsql: bufmgr: Implement buffer content locks independently of lwlocks

bufmgr: Implement buffer content locks independently of lwlocks Until now buffer content locks were implemented using lwlocks. That has the obvious advantage of not needing a separate efficient implementation of locks. However, the time for a dedicated buffer content lock implementation has come:

pgsql: bufmgr: Change BufferDesc.state to be a 64-bit atomic

bufmgr: Change BufferDesc.state to be a 64-bit atomic This is motivated by wanting to merge buffer content locks into BufferDesc.state in a future commit, rather than having a separate lwlock (see commit c75ebc657ff for more details). As this change is rather mechanical, it seems to make sense to

pgsql: Fix 'unexpected data beyond EOF' on replica restart

Fix 'unexpected data beyond EOF' on replica restart On restart, a replica can fail with an error like 'unexpected data beyond EOF in block 200 of relation T/D/R'. These are the steps to reproduce it: - A relation has a size of 400 blocks. - Blocks 201 to 400 are empty. - Block 200 has two row

pgsql: Fix 'unexpected data beyond EOF' on replica restart

Fix 'unexpected data beyond EOF' on replica restart On restart, a replica can fail with an error like 'unexpected data beyond EOF in block 200 of relation T/D/R'. These are the steps to reproduce it: - A relation has a size of 400 blocks. - Blocks 201 to 400 are empty. - Block 200 has two row

pgsql: Fix 'unexpected data beyond EOF' on replica restart

Fix 'unexpected data beyond EOF' on replica restart On restart, a replica can fail with an error like 'unexpected data beyond EOF in block 200 of relation T/D/R'. These are the steps to reproduce it: - A relation has a size of 400 blocks. - Blocks 201 to 400 are empty. - Block 200 has two row

pgsql: Fix 'unexpected data beyond EOF' on replica restart

Fix 'unexpected data beyond EOF' on replica restart On restart, a replica can fail with an error like 'unexpected data beyond EOF in block 200 of relation T/D/R'. These are the steps to reproduce it: - A relation has a size of 400 blocks. - Blocks 201 to 400 are empty. - Block 200 has two row

pgsql: Fix 'unexpected data beyond EOF' on replica restart

Fix 'unexpected data beyond EOF' on replica restart On restart, a replica can fail with an error like 'unexpected data beyond EOF in block 200 of relation T/D/R'. These are the steps to reproduce it: - A relation has a size of 400 blocks. - Blocks 201 to 400 are empty. - Block 200 has two row

pgsql: Fix 'unexpected data beyond EOF' on replica restart

Fix 'unexpected data beyond EOF' on replica restart On restart, a replica can fail with an error like 'unexpected data beyond EOF in block 200 of relation T/D/R'. These are the steps to reproduce it: - A relation has a size of 400 blocks. - Blocks 201 to 400 are empty. - Block 200 has two row

pgsql: Optimize LISTEN/NOTIFY via shared channel map and direct advance

Optimize LISTEN/NOTIFY via shared channel map and direct advancement. This patch reworks LISTEN/NOTIFY to avoid waking backends that have no need to process the notification messages we just sent. The primary change is to create a shared hash table that tracks which processes are listening to whi

pgsql: lwlock: Remove ForEachLWLockHeldByMe

lwlock: Remove ForEachLWLockHeldByMe As of commit fcb9c977aa5, ForEachLWLockHeldByMe(), introduced in f4ece891fc2f, is not used anymore, as content locks are now implemented in bufmgr.c. It doesn't seem that likely that a new user of the functionality will appear all that soon, making removal of

pgsql: pgindent fix for 8077649907d

pgindent fix for 8077649907d Per buildfarm member koel. Backpatch-through: 18 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/335f2231a30cb5002219888eef14f4dfce5b0391 Modified Files -- src/backend/storage/aio/method_io_uring.c | 2 +- 1 file changed, 1

pgsql: lwlock: Remove support for disowned lwlwocks

lwlock: Remove support for disowned lwlwocks This reverts commit f8d7f29b3e81db59b95e4b5baaa6943178c89fd8, plus parts of subsequent commits fixing a typo in a parameter name. Support for disowned lwlocks was added for the benefit of AIO, to be able to have content locks "owned" by the AIO subsyst

pgsql: Fix segfault from releasing locks in detached DSM segments

Fix segfault from releasing locks in detached DSM segments If a FATAL error occurs while holding a lock in a DSM segment (such as a dshash lock) and the process is not in a transaction, a segmentation fault can occur during process exit. The problem sequence is: 1. Process acquires a lock in a

Re: pgsql: Fix segfault from releasing locks in detached DSM segments

Amit Langote writes: > Fix segfault from releasing locks in detached DSM segments > ... > Backpatch-through: 14 I see no back-patch commits? regards, tom lane

pgsql: Fix stability issue with new TAP test of pg_createsubscriber

Fix stability issue with new TAP test of pg_createsubscriber The test introduced in 639352d904c8 has added a direct pg_ctl command to start a node, a method that is incompatible with the teardown() routine used at the end of the test as the PID saved in the Cluster object would prevent the node to

pgsql: Fix segfault from releasing locks in detached DSM segments

Fix segfault from releasing locks in detached DSM segments If a FATAL error occurs while holding a lock in a DSM segment (such as a dshash lock) and the process is not in a transaction, a segmentation fault can occur during process exit. The problem sequence is: 1. Process acquires a lock in a

pgsql: Fix segfault from releasing locks in detached DSM segments

Fix segfault from releasing locks in detached DSM segments If a FATAL error occurs while holding a lock in a DSM segment (such as a dshash lock) and the process is not in a transaction, a segmentation fault can occur during process exit. The problem sequence is: 1. Process acquires a lock in a

pgsql: Fix segfault from releasing locks in detached DSM segments

Fix segfault from releasing locks in detached DSM segments If a FATAL error occurs while holding a lock in a DSM segment (such as a dshash lock) and the process is not in a transaction, a segmentation fault can occur during process exit. The problem sequence is: 1. Process acquires a lock in a

pgsql: Fix segfault from releasing locks in detached DSM segments

Fix segfault from releasing locks in detached DSM segments If a FATAL error occurs while holding a lock in a DSM segment (such as a dshash lock) and the process is not in a transaction, a segmentation fault can occur during process exit. The problem sequence is: 1. Process acquires a lock in a

pgsql: Fix segfault from releasing locks in detached DSM segments

Fix segfault from releasing locks in detached DSM segments If a FATAL error occurs while holding a lock in a DSM segment (such as a dshash lock) and the process is not in a transaction, a segmentation fault can occur during process exit. The problem sequence is: 1. Process acquires a lock in a

Re: pgsql: Fix segfault from releasing locks in detached DSM segments

On Fri, Jan 16, 2026 at 1:45 PM Tom Lane wrote: > Amit Langote writes: > > Fix segfault from releasing locks in detached DSM segments > > ... > > Backpatch-through: 14 > > I see no back-patch commits? Push-script malfunction. Fixed. -- Thanks, Amit Langote

pgsql: Fix rowmark handling for non-relation RTEs during executor init

Fix rowmark handling for non-relation RTEs during executor init Commit cbc127917e introduced tracking of unpruned relids to skip processing of pruned partitions. PlannedStmt.unprunableRelids is computed as the difference between PlannerGlobal.allRelids and prunableRelids, but allRelids only contai

pgsql: Fix rowmark handling for non-relation RTEs during executor init

Fix rowmark handling for non-relation RTEs during executor init Commit cbc127917e introduced tracking of unpruned relids to skip processing of pruned partitions. PlannedStmt.unprunableRelids is computed as the difference between PlannerGlobal.allRelids and prunableRelids, but allRelids only contai

pgsql: Improve pg_clear_extended_stats() with incorrect relation/stats

Improve pg_clear_extended_stats() with incorrect relation/stats combination Issue fat-fingered in d756fa1019ff, noticed while doing more review of the main patch set proposed. I have missed the fact that this can be triggered by specifying an extended stats object that does not match with the rel

pgsql: plpython: Remove duplicate PyModule_Create()

plpython: Remove duplicate PyModule_Create() This seems to have existed like this since Python 3 support was added (commit dd4cd55c158), but it's unclear what this second call is supposed to accomplish. Reviewed-by: Chao Li Reviewed-by: Matheus Alcantara Reviewed-by: li carol Reviewed-by: Kiri

pgsql: plpython: Streamline initialization

plpython: Streamline initialization The initialization of PL/Python (the Python interpreter, the global state, the plpy module) was arranged confusingly across different functions with unclear and confusing boundaries. For example, PLy_init_interp() said "Initialize the Python interpreter ..." bu