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 →
-
Generic Messages for Logical Decoding
- 3fe3511d0512 9.6.0 cited