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

Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>

From: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
To: 'torikoshia' <torikoshia@oss.nttdata.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, "nagata@sraoss.co.jp" <nagata@sraoss.co.jp>
Cc: "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2026-06-18T08:27:10Z
Lists: pgsql-hackers
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.

Best regards,
Hayato Kuroda
FUJITSU LIMITED




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