| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
|---|---|
| To: | vignesh C <vignesh21(at)gmail(dot)com> |
| Cc: | 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-04 09:09:54 |
| Message-ID: | CAA4eK1+17UXN7z1qV+c61cWvCY-K5b00hsjwfWM82SpfQi9QTw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Oct 8, 2026 at 11:31 AM vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> While reviewing another thread at [1], I found an issue where an error
> relayed from a parallel apply worker can get an unrelated CONTEXT line
> from the leader process.
> ProcessParallelApplyMessage() in applyparallelworker.c sets
> error_context_stack to the leader's apply_error_context_stack before
> calling ereport(ERROR). As a result, when errfinish() processes the
> error, the leader's error context callback runs again and adds the
> leader's current replication context. This can be incorrect if the
> leader is processing a different transaction when it receives the
> error from the parallel worker. For example, in my test:
> tab_a is processed by a parallel worker and fails due to a trigger.
>
> The leader is processing an unrelated insert into tab_b. The parallel
> worker's error is received while the leader is processing tab_b. The
> final error incorrectly contains context for both tab_a and tab_b. The
> resulting error looks like:
> ERROR: logical replication parallel apply worker exited due to error
> 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
> processing remote data ... relation "public.tab_b" ...
>
> The tab_b context is unrelated to the actual failure and comes from
> the leader's current activity.
>
OTOH, the leader apply worker also exited due to this ERROR, so
showing what the leader worker was doing via CONTEXT information is
also not a bad idea. However, I think it is difficult to make out with
the current display of this message. 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(). 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.
--
With Regards,
Amit Kapila.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Koshino Taiki | 2026-11-04 09:18:11 | Re: [PATCH v1] psql: Do not complete HEADER MATCH for COPY TO |
| Previous Message | Bertrand Drouvot | 2026-11-04 09:09:42 | Re: Fix ReadStream handling when heap rescan strategy changes |