| From: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> |
|---|---|
| To: | 'Amit Kapila' <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, vignesh C <vignesh21(at)gmail(dot)com> |
| Subject: | RE: Incorrect CONTEXT reported for errors from parallel apply worker in logical replication |
| Date: | 2026-11-04 13:57:01 |
| Message-ID: | OS7PR01MB183177947F9F4CD32B802A266F5682@OS7PR01MB18317.jpnprd01.prod.outlook.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Amit,
Thanks for giving comment!
> One thing we can try to see what
> if ProcessParallelApplyMessage() instead of throwing an explicit ERROR
> just rethrows what it gets from the parallel apply worker by using
> ThrowErrorData().
To confirm, apply_loop_outer_error_context_stack is anyway needed even if we use
ThrowErrorData(), right? Otherwise the output can be like [1], context from leader
worker can exist without any marks.
IIUC ThrowErrorData() has benefits that 1) SQLSTATE can be preserved and 2) we
can make the shape of codes similar. Parallel workers and REPACK workers has the same.
But I do not have preference here. 0002 implements this.
> The other idea to make this information meaningful
> is to display it in something like:
> CONTEXT: PL/pgSQL function public.tab_a_boom_fn() line 3 at RAISE
> processing remote data ... relation "public.tab_a" ...
> logical replication parallel apply worker
> leader apply worker was processing:
> processing remote data ... relation "public.tab_b" ...
>
> This will make it clear what the leader worker was processing during
> the ERROR. I think for this we may need to register a leader specific
> error-callback.
0003 tried the idea. Per my understanding we can introduce an ephemeral error
context to append the leader's work.
How do you feel?
[1]:
ERROR: tab_a trigger boom
CONTEXT: PL/pgSQL function public.tab_a_boom_fn() line 3 at RAISE
processing remote data for replication origin "pg_16409" during message type "INSERT" for replication target relation "public.tab_a" in transaction 667
logical replication parallel apply worker
processing remote data for replication origin "pg_16409" during message type "INSERT" for replication target relation "public.tab_b" in transaction 668, finished at 0/0182EEF
Best regards,
Hayato Kuroda
FUJITSU LIMITED
| Attachment | Content-Type | Size |
|---|---|---|
| v7-0001-Test-to-reproduce-parallel-apply-error-context-is.patch | application/octet-stream | 10.0 KB |
| v7-0002-Avoid-adding-leader-apply-context-to-parallel-wor.patch | application/octet-stream | 6.8 KB |
| v7-0003-Distinguish-leader-context-in-parallel-apply-work.patch | application/octet-stream | 5.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ruohang Feng | 2026-11-04 14:10:04 | Re: Credits For v19 |
| Previous Message | Hữu Đôn Hoàng | 2026-11-04 13:56:56 | Re: Print latency percentiles in pgbench |