| From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
|---|---|
| To: | Ayush Tiwari <ayushtiwari(dot)slg01(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-07-08 03:21:32 |
| Message-ID: | CAHGQGwF6z8Df19WPX8ufbDvGBT7_5CEkxk7Q1K1LMwqPHbccFg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jun 15, 2026 at 10:42 PM Ayush Tiwari
<ayushtiwari(dot)slg01(at)gmail(dot)com> wrote:
>
> 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.
Thanks for the review! I've pushed the patch.
Regards,
--
Fujii Masao
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | cca5507 | 2026-07-08 02:36:38 | Re: Do not lock tables in get_tables_to_repack |