| From: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> |
|---|---|
| To: | 'torikoshia' <torikoshia(at)oss(dot)nttdata(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, "nagata(at)sraoss(dot)co(dot)jp" <nagata(at)sraoss(dot)co(dot)jp> |
| Cc: | "pgsql-hackers(at)lists(dot)postgresql(dot)org" <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-18 08:27:10 |
| Message-ID: | OS9PR01MB12149C82E87FFEDE2653E433AF5E32@OS9PR01MB12149.jpnprd01.prod.outlook.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tatsuo Ishii | 2026-06-18 08:27:47 | Re: IGNORE/RESPECT NULLS can be specified for (prokind == 'f'). |
| Previous Message | Chao Li | 2026-06-18 08:17:43 | Re: IGNORE/RESPECT NULLS can be specified for (prokind == 'f'). |