Re: pg_recvlogical: send final feedback on SIGINT/SIGTERM exit

Поиск
Список
Период
Сортировка
Искать

Re: pg_recvlogical: send final feedback on SIGINT/SIGTERM exit

От:
Fujii Masao <masao.fujii@gmail.com>
Дата:
On Mon, Jun 15, 2026 at 10:42 PM Ayush Tiwari
 wrote:
>
> Hi,
>
> On Fri, 29 May 2026 at 05:42, Fujii Masao  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


Re: pg_recvlogical: send final feedback on SIGINT/SIGTERM exit

От:
Ayush Tiwari <ayushtiwari.slg01@gmail.com>
Дата:
Hi,

On Fri, 29 May 2026 at 05:42, Fujii Masao <masao.fujii@gmail.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 

pgsql: Fix stale comment in parallel_vacuum_main().

От:
Masahiko Sawada <msawada@postgresql.org>
Дата:
Fix stale comment in parallel_vacuum_main().

The comment claimed that a parallel vacuum worker has only the
PROC_IN_VACUUM flag because parallel vacuum is not supported for
autovacuum, but commit 1ff3180ca01 allowed autovacuum to use parallel
vacuum workers.

The assertion itself still holds: the leader, whether a backend
running VACUUM or an autovacuum worker, sets PROC_IN_VACUUM before
taking its snapshot, and a parallel worker inherits the flag when
importing the leader's snapshot. The leader's other flags don't reach
the worker, since the snapshot import copies only the PROC_XMIN_FLAGS
bits and PROC_IS_AUTOVACUUM is never set on parallel workers, which
run as regular background workers. Reword the comment to explain that.

Oversight in commit 1ff3180ca01.

Author: Bharath Rupireddy 
Reviewed-by: Masahiko Sawada 
Reviewed-by: Chao Li 
Discussion: https://postgr.es/m/CALj2ACVwQ4WABqq8Lnf+VZEJ45jcTFhyFLFr_ctfS4=QLL-r5w@mail.gmail.com
Backpatch-through: 19

Branch
------
REL_19_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/4ee0ccfd55f973160a2ab013bc96488715221270

Modified Files
--------------
src/backend/commands/vacuumparallel.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)

FAQ