| From: | vignesh C <vignesh21(at)gmail(dot)com> |
|---|---|
| To: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> |
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Incorrect CONTEXT reported for errors from parallel apply worker in logical replication |
| Date: | 2026-11-05 09:07:54 |
| Message-ID: | CALDaNm2kQWPiv7P9ci0zmLszw7xUij=S6esds9+f4Jm+1nB0tw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 4 Nov 2026 at 19:27, Hayato Kuroda (Fujitsu)
<kuroda(dot)hayato(at)fujitsu(dot)com> wrote:
>
> 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?
Thanks for the patches.
With 0002 and 0003, the leader's entry still contains the error of the
parallel apply worker, or its context, followed by the context of the
leader's own transaction. The error of a different process then sits
next to the leader's context, and the context of the failed
transaction is logged a second time. This can be misleading.
Kuroda-san and me had an offline discussion and came up with the
following approach: The parallel apply worker will reports its error
with the context of the failed transaction, and the leader only says
that the worker failed, with its own context like:
logical replication parallel worker[17710] ERROR: tab_a trigger boom
logical replication parallel worker[17710] CONTEXT: PL/pgSQL function
public.tab_a_boom_fn() line 3 at RAISE
processing remote data for replication origin "pg_16411"
during message type "INSERT" for replication target relation
"public.tab_a" in transaction 667
logical replication apply worker[17698] ERROR: logical replication
parallel apply worker exited due to error, exiting leader as well
logical replication apply worker[17698] CONTEXT: processing remote
data for replication origin "pg_16411" during message type "INSERT"
for
replication target relation "public.tab_b" in transaction 668,
finished at 0/0177DBA0
postmaster[17642] LOG: background worker "logical replication
parallel worker" (PID 17710) exited with exit code 1
postmaster[17642] LOG: background worker "logical replication apply
worker" (PID 17698) exited with exit code 1
That way the transaction is not logged a second time, and the error of
another process is no longer attached next to the leader's context.
Thanks Kuroda-san for the offline discussion.
The attached v8 version patch has the changes to drop the copying of
the worker's context, keeps the pinned context stack, and changes the
message.
Thoughts?
Regards,
Vignesh
| Attachment | Content-Type | Size |
|---|---|---|
| v8-0001-Fix-the-error-context-of-the-leader-apply-worker-.patch | application/octet-stream | 2.9 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2026-11-05 09:12:08 | Re: [Bug Report + Patch] File descriptor leak when io_method=io_uring |
| Previous Message | Peter Eisentraut | 2026-11-05 09:03:10 | Re: Fix translation error in zh_CN.po for "parameter specified more than once" |