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

torikoshia <torikoshia@oss.nttdata.com>

From: torikoshia <torikoshia@oss.nttdata.com>
To: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, nagata@sraoss.co.jp, pgsql-hackers@lists.postgresql.org
Date: 2026-06-19T01:59:56Z
Lists: pgsql-hackers
On 2026-06-18 17:27, Hayato Kuroda (Fujitsu) wrote:
> Dear Torikoshi-san,
> 
> Sorry for the late join...
> 
>> With the current behavior, consumers need to be aware that only
>> logical messages return endptr (and this does not appear to be
>> documented, so one would have to discover it through testing).
>> Then they need special handling to translate the completion LSN
>> for logical messages back to the previous processing position.
> Actually I did not recognize till I found the thread, and I'm also 
> unclear
> the reason of the difference. From my perspective any blockers within
> core are not found.
> 
>> For example, I wonder whether Fujitsu's 'Userlog Operation' might
>> also be affected:
>> https://www.postgresql.fastware.com/hubfs/_Global/Manuals/FEP-v17forx86-
>> UserlogOperationGuide.pdf
>> 
> 
> FYI, I confirmed the proprietary won't be affected by the change you 
> proposed.

Thanks for your confirmation! I appreciate that.

On 2026-06-11 11:27, torikoshia wrote:
> On this point, I have started discussing with the Debezium
> community, where I originally encountered this issue. The main
> question is whether a change in PostgreSQL's behavior would be
> welcomed, or whether Debezium instead treats logical messages
> differently from other decoded records.

FYI, this discussion is still ongoing.

--
Atsushi Torikoshi



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Generic Messages for Logical Decoding