Subject: Fix incorrect assignment for nodeid in TransactionIdGetCommitTsData()

From: wangpeng <[email-masked]>
Date: Thu, 5 Feb 2026 11:38:37 +0800

Hi hackers,

This is my first patch
There is an incorrect assignment of nodeid = 0 in 
TransactionIdGetCommitTsData() (commit_ts.c).
Elsewhere in the file, the code consistently uses InvalidReplOriginId.
Even though InvalidReplOriginId also evaluates to 0, it should be used 
here for clarity and consistency.

Best regards,
Wang Peng
From 986f7499e63b1b4e97edb95ef98b0260fab3a9ff Mon Sep 17 00:00:00 2001
From: Wang Peng <[email-masked]>
Date: Wed, 4 Feb 2026 21:47:44 -0500
Subject: [PATCH v1] Subject: Fix incorrect assignment for nodeid 
 TransactionIdGetCommitTsData()
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

There is a incorrect assignment for nodeid.
Which should be ‘InvalidReplOriginId’ instead of ‘0’.

Author: Wang Peng <[email-masked]>
---
 src/backend/access/transam/commit_ts.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/backend/access/transam/commit_ts.c b/src/backend/access/transam/commit_ts.c
index 6fa2178..57ae04e 100644
--- a/src/backend/access/transam/commit_ts.c
+++ b/src/backend/access/transam/commit_ts.c
@@ -288,7 +288,7 @@ TransactionIdGetCommitTsData(TransactionId xid, TimestampTz *ts,
 		/* frozen and bootstrap xids are always committed far in the past */
 		*ts = 0;
 		if (nodeid)
-			*nodeid = 0;
+			*nodeid = InvalidReplOriginId;
 		return false;
 	}
 
-- 
1.8.3.1

---

From: Ashutosh Bapat <[email-masked]>
Date: Thu, 5 Feb 2026 20:30:43 +0530

> This is my first patch

Welcome to the community.

> here for clarity and consistency.

Few lines below we have a similar assignment which uses
InvalidReplOriginId. I agree with your suggestion. Patch LGTM. It's an
old and small commit so maybe Alvaro, who committed the change
(4aaddf2f009821e29aea3735e44332ad9ca47aaa), may not remember it. Still
including him in case.

-- 
Best Wishes,
Ashutosh Bapat

---

From: Chao Li <[email-masked]>
Date: Tue, 10 Feb 2026 09:35:26 +0800

> On Feb 5, 2026, at 23:00, Ashutosh Bapat <[email-masked]> wrote:
> 

+1. I saw a recent commit, ec317440716487753bafa4c0f8adae53e2c32446, which replaces 0 with InvalidXLogRecPtr, so this patch is similar. The main difference is that ec3174407 does a broad sweep replacing 0 wherever possible, while this patch just fixes one remaining omission.

So if this patch is considered too trivial, I think it’s still worth a place in Michael’s stack for later.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

---

From: Bertrand Drouvot <[email-masked]>
Date: Thu, 12 Feb 2026 10:16:50 +0000

Hi,

On Tue, Feb 10, 2026 at 09:35:26AM +0800, Chao Li wrote:
> while this patch just fixes one remaining omission.

I did check with the same kind of Coccinelle script used for ec317440716 and
it looks like the proposed change here for InvalidReplOriginId is the only one
to fix for the ReplOriginId type.

FWIW, I extended the exercise for other Invalid* values in [1].

[1]: https://postgr.es/m/aY2oKlSpikgO9m%2BX%40ip-10-97-1-34.eu-west-3.compute.internal

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

---

From: Michael Paquier <[email-masked]>
Date: Wed, 4 Mar 2026 09:21:14 +0900

> a place in Michael’s stack for later.

Aye.  I did not notice this one first, but Alvaro has poked me about
it, so grabbed now for later.
--
Michael

---

From: Paul Bunn <[email-masked]>
Date: Wed, 4 Mar 2026 00:36:09 +0000 (GMT)

Hi hackers, We've identified a bug in the DSA (Dynamic Shared Memory Area) allocator that causes memory corruption and crashes during parallel hash joins with large data sets. The bug has been present since the DSA implementation was introduced and affects all supported branches. Attached is a minimal fix (5 lines added, 0 changed). == Bug Summary == In make_new_segment() (src/backend/utils/mmgr/dsa.c), there are two paths for computing segment layout: Path 1 (geometric): knows total_size upfront, computes total_pages = total_size / FPM_PAGE_SIZE pagemap entries = total_pages <-- correct Path 2 (odd-sized, when requested > geometric): works forward from usable_pages = requested_pages pagemap entries = usable_pages <-- BUG The pagemap is indexed by absolute page number. The FreePageManager hands out pages with indices from metadata_pages to (metadata_pages + usable_pages - 1). Since metadata_pages >= 1, page indices at the high end of the range exceed usable_pages, making the pagemap accesses out-of-bounds. == How It Was Found on Postgres 15 == Multiple parallel worker backends crashed simultaneously with SIGSEGV in dsa_get_address(), called from dsa_free() in ExecHashTableDetachBatch() during parallel hash join batch cleanup. Stack trace: #0 dsa_get_address (area, dp) at dsa.c:955 #1 dsa_free (area, dp) at dsa.c:839 #2 ExecHashTableDetachBatch (hashtable) at nodeHash.c:3189 #3 ExecParallelHashJoinNewBatch (hjstate) at nodeHashjoin.c:1157 All crashing workers computed the same pageno (196993), which was the last valid FPM page but beyond the pagemap array (usable_pages = 196609). == Root Cause (from core dump analysis) == The crashing segment had: usable_pages = 196,609 (pagemap has this many entries) metadata_pages = 385 total_pages = 196,994 (= metadata_pages + usable_pages) last FPM page = 196,993 (= metadata_pages + usable_pages - 1) pagemap valid indices: 0 .. 196,608 FPM page indices: 385 .. 196,993 Pages 196,609 through 196,993 (385 pages) have no valid pagemap entry. The pagemap array ends 3,072 bytes before the data area starts (padding zone). Most out-of-bounds entries fall in this padding and cause silent corruption. The last 17 entries fall in the data area itself, causing bidirectional corruption: pagemap writes destroy allocated object data, and subsequent pagemap reads return garbage, crashing dsa_free(). == The Fix == After computing metadata_bytes with usable_pages pagemap entries, add entries for the metadata pages themselves: metadata_bytes += ((metadata_bytes / (FPM_PAGE_SIZE - sizeof(dsa_pointer))) + 1) * sizeof(dsa_pointer); The divisor (FPM_PAGE_SIZE - sizeof(dsa_pointer)) = 4088 accounts for the circular dependency: each metadata page costs one pagemap entry (8 bytes), so only 4088 of each 4096-byte metadata page is net-free for other pagemap entries. The +1 absorbs the ceiling. -- Hopefully I've followed the correct format for creating a patch -- this is my first post here. Thanks, Paul

---

From: Michael Paquier <[email-masked]>
Date: Wed, 4 Mar 2026 09:52:18 +0900

On Wed, Mar 04, 2026 at 12:36:09AM +0000, Paul Bunn wrote:
> The +1 absorbs the ceiling. -- Hopefully I've
> followed the correct format for creating a patch -- this is my first
> post here.

The email you have sent with the patch attached is a bit weird.  First
it renders incorrectly on the website, same way as my email client:
https://www.postgresql.org/message-id/ba161ba1-9d5f-409d-9826-40d076d4ca2b%40me.com

Then, this is attached to an existing thread.  You should not do that
for clarity.

Anyway, about the patch, could you provide a self-contained SQL
sequence that proves your point?  That would be helpful in terms of
analyzing what you think is a problem and what you think could be a
potential solution.
--
Michael