RE: Incorrect CONTEXT reported for errors from parallel apply worker in logical replication

Dear Vignesh,

> Thanks for the patch, the issue is resolved with your patch. One suggestion:
> Can we add a comment saying the saved stack deliberately excludes
> apply_error_callback. That would stop someone from "fixing" it back
> later:

Added. Also, I updated the comment in ProcessParallelApplyMessage().

> > BTW, I also checked the REPACK CONCURRENTLY, but it seemed to have the
> same issue
> > as the parallel apply. I locally found a reproducer and wrote a fix patch,
> > I can share here or another place.
>
> I felt we can discuss here itself as the fix should be similar for
> both the cases and reviewing also would be easier.

OK, then let me attach and describe once. 0003 is the reproducer, and 0004 is the fix
patch.

001_repack_error_context reproduced the issue. A functional index is defined with
the injection point. While the backend waits at the point the repack worker does
the error out (also by the injection point). In this case the backend re-throws
the propagated from the repack worker, so the unrelated context can be printed.
Below is the obtained result, lines after the "SQL statement..." is not propagated
from the repack worker.

```
ERROR: error triggered for injection point repack-worker-error-context
CONTEXT: REPACK decoding worker
SQL statement "SELECT public.injection_points_run('repack-leader-error-context')"
PL/pgSQL function public.repack_error_context(integer) line 3 at PERFORM
```

This means the misleading lines in CONTEXT can be reported if the backend
installed the transient callbacks while processing tuples.

The fix idea is to preserve the context like parallel query. I added an attribute
in the DecodingWorker which controls the repack worker. It's preserved when the
worker is started, and it's restored when the backend reports the log.
It's mostly same as ProcessParallelMessage().

Best regards,
Hayato Kuroda
FUJITSU LIMITED