Re: Fix incorrect assignment of InvalidXLogRecPtr to a non-LSN variable.
Steven Niu <niushiji@gmail.com>
From: Steven Niu <niushiji@gmail.com>
To: Fujii Masao <masao.fujii@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-11-12T08:47:20Z
Lists: pgsql-hackers
Agreed. The definitions of upto_lsn and upyo_nchanges are different, so they should not be assigned the same form of value. XLogRecPtr upto_lsn; int32 upto_nchanges; ...... if (PG_ARGISNULL(1)) upto_lsn = InvalidXLogRecPtr; else upto_lsn = PG_GETARG_LSN(1); if (PG_ARGISNULL(2)) upto_nchanges = InvalidXLogRecPtr; else upto_nchanges = PG_GETARG_INT32(2); Thanks, Steven ________________________________ From: Fujii Masao <masao.fujii@gmail.com> Sent: Wednesday, November 12, 2025 16:23 To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org> Subject: Fix incorrect assignment of InvalidXLogRecPtr to a non-LSN variable. Hi, I noticed that pg_logical_slot_get_changes_guts() assigns InvalidXLogRecPtr to the local variable upto_nchanges, even though it's not LSN variable (i.e., its type is int32, not XLogRecPtr). While this causes no functional issue since InvalidXLogRecPtr is defined as 0, it's semantically incorrect. I propose fixing this by setting upto_nchanges to 0 instead of InvalidXLogRecPtr. Attached is a patch implementing this change. Regards, -- Fujii Masao
Commits
-
Fix incorrect assignment of InvalidXLogRecPtr to a non-LSN variable.
- 705601c5aeab 19 (unreleased) landed