On Tue, 6 Oct 2026 at 12:07, Hayato Kuroda (Fujitsu) <[email protected]> wrote: > > Hi Vignesh, > > > I was planning to review this patch set and noticed the patch does not > > apply anymore, could you post a rebased version for reviewing? > > Thanks for the contact. Here is an updated version.
I ran into a reliability issue in pa_send_data()
(src/backend/replication/logical/applyparallelworker.c).
pa_send_data() retries shm_mq_send() for SHM_SEND_TIMEOUT_MS(9)
seconds when the parallel apply worker is slow to consume its input.
If it still cannot send the data, it returns false. All its callers in
worker.c treat this as a hard error and terminate the apply worker:
ereport(ERROR, ...,
errmsg("could not send data to the logical replication "
"parallel apply worker"));
This can happen during a normal temporary delay in consuming the data.
For example, if the leader has more than 16 MB of changes to send
before the parallel worker catches up, pa_send_data() can time out and
bring down the apply worker. With disable_on_error, this can disable
the entire subscription due to a temporary delay in processing the
data. Without it, the apply worker is restarted and can hit the same
failure again. I felt that treating a slow parallel apply worker as an
error condition does not seem right, since this is an expected
situation during normal processing.
I have attached a patch with a test that reproduces the issue.
Regards,
Vignesh
0001-Test-to-show-a-slow-worker-brings-down-logical-repli.patch
Description: Binary data
