| From: | Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: pg_recvlogical: send final feedback on SIGINT/SIGTERM exit |
| Date: | 2026-06-15 13:41:51 |
| Message-ID: | CAJTYsWVftJZdWXrppHZ+u-zN__J6ae01AS=scNnLUFXGS_cFYQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On Fri, 29 May 2026 at 05:42, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>
> 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.
>
Thanks for the patch!
The problem statement and solution makes sense to me.
I applied v1 and tried it locally. It builds cleanly and the new block in
030_pg_recvlogical.pl passes. As a sanity check I reverted just the
prepareToTerminate() change and kept the test: the "does not duplicate
decoded
changes after signal shutdown" assertion then fails (the row is decoded
twice
on the restart), so the test is clearly exercising the fix too. I don't see
any
downside of having the fix attached.
> 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.
>
Agreed that this is a best-effort improvement rather than a guarantee, and
targeting v20 seems reasonable.
Regards,
Ayush
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2026-06-15 13:43:35 | Re: BackgroundPsql swallowing errors on windows |
| Previous Message | Bertrand Drouvot | 2026-06-15 13:40:17 | Allow wal_log_hints to be changed without restart |