Re: Fix incorrect assignment of InvalidXLogRecPtr to a non-LSN variable.

From: Steven Niu <niushiji(at)gmail(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Fix incorrect assignment of InvalidXLogRecPtr to a non-LSN variable.
Date: 2025-11-12 08:47:20
Message-ID: MN2PR15MB302157CF81E30E07D5E4FA25A7CCA@MN2PR15MB3021.namprd15.prod.outlook.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
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(dot)fujii(at)gmail(dot)com>
Sent: Wednesday, November 12, 2025 16:23
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2025-11-12 09:09:28 Re: Make PQgetResult() not return NULL on out-of-memory error
Previous Message Sergey Tatarintsev 2025-11-12 08:46:33 Re: pg_getaddrinfo_all() with hintp=NULL