Re: Why is the LSN reported for pg_logical_emit_message() different from other decoded operations?

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: nagata(at)sraoss(dot)co(dot)jp
Cc: torikoshia(at)oss(dot)nttdata(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Why is the LSN reported for pg_logical_emit_message() different from other decoded operations?
Date: 2026-06-09 07:59:38
Message-ID: 20260609.165938.1404018771983205660.horikyota.ntt@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello.

At Tue, 9 Jun 2026 11:23:32 +0900, Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp> wrote in
> Based on my reading, the current behavior does not seem to match that
> description. However, if reporting the end LSN is intentional, perhaps
> the documentation should be updated to clarify that.

Looking at the existing code, PostgreSQL appears to use the start LSN
for most record types, except for a few special cases such as COMMIT
records.

As for logical decoding messages, their contents are not sent to the
subscriber in the first place. Even if they were, the subscriber would
only use them to advance its received LSN. From that perspective,
PostgreSQL does not seem to care whether the LSN associated with a
message record refers to the beginning or the end of the WAL record.

Of course, this raises the question of whether any existing extension
relies on the current behavior. I don't know the answer to that.

That said, the documentation says:

https://www.postgresql.org/docs/devel/protocol-logicalrep-message-formats.html

> Message
....
> Int64 (XLogRecPtr)
> The LSN of the logical decoding message.

The value currently comes from XLogRecordBuffer.endptr, which is
passed to logicalmsg_decode(). If the documentation is correct, then
it seems to me that this should instead use origptr.

Regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2026-06-09 08:05:23 Reject negative max_retention_duration values
Previous Message Xuneng Zhou 2026-06-09 07:49:50 Re: t/035_standby_logical_decoding.pl might fail on attempt to read wrong timeline