| From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | pg_recvlogical: send final feedback on SIGINT/SIGTERM exit |
| Date: | 2026-05-29 00:11:45 |
| Message-ID: | CAHGQGwE83z9O=X7ADMsSa3e1EuP3_GgqHjFt5SmPDNxZo_wgJA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
I'd like to propose an improvement for pg_recvlogical.
Currently, when pg_recvlogical exits due to SIGINT or SIGTERM, it can
terminate after writing decoded output locally but before sending feedback
that reflects the latest written position to the server. If pg_recvlogical
is restarted after that, the server-side logical replication slot may still
remain behind those already-written changes, and the same decoded data can
be sent again.
Attached patch makes pg_recvlogical send final feedback once more during
SIGINT/SIGTERM exit, before sending CopyDone. That gives the server one more
chance to advance the slot far enough to avoid resending already-written
data after pg_recvlogical is restarted.
One note is that this is still only a best-effort improvement.
Depending on when SIGINT or SIGTERM arrives, pg_recvlogical may already have
written decoded output that the server cannot yet safely treat as confirmed,
so duplicate data can still be received after restart. In other words, this
patch reduces the likelihood of duplicates, but does not guarantee that they
will never happen.
I see this as an improvement to pg_recvlogical behavior rather than a
bug fix, so I think it should target v20.
Regards,
--
Fujii Masao
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-pg_recvlogical-send-final-feedback-on-SIGINT-SIGT.patch | application/octet-stream | 5.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chao Li | 2026-05-29 00:42:40 | Re: [PATCH] Improve REPACK (CONCURRENTLY) error messages for unsupported configurations |
| Previous Message | Amit Kapila | 2026-05-28 23:41:34 | Re: Proposal: Conflict log history table for Logical Replication |