Re: Orphaned records in pg_replication_origin_status after subscription drop - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Orphaned records in pg_replication_origin_status after subscription drop
Date
Msg-id CAA4eK1+-U-1V0VH02byaA3anUyS0VK3kO1SBKhYJcL-o0BMAyQ@mail.gmail.com
Whole thread Raw
In response to Re: Orphaned records in pg_replication_origin_status after subscription drop  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
On Sat, Dec 20, 2025 at 3:27 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> I am slightly leaning towards the idea of using a short transaction
> because the tablesync worker would do things closer to the apply
> workers and it would also fix the odd behavior that
> pg_replication_origin_status shows NULL in the external_id column for
> the origins while the COPY is being executed. But we need to verify if
> it's really okay to reuse the existing origin instead of raising an
> error in case where the tablesync worker retries to the data copy.
>

As of today, I can't think of a case where next time (restart after
error) we won't generate the same origin_name but I think this will
add the dependency that each time the origin name should be generated
the same. Also, moving just repl_origin_create part (leaving other
things like origin_advance at its location) would need some
explanation in comments which is that it has some dependency on
DropSubscription and cleanup. Anyway, if we want to go with creating
origin in a separate transaction than COPY, then we should change few
comments like: "It is possible that the origin is not yet created for
tablesync worker, this can happen for the states before
SUBREL_STATE_FINISHEDCOPY." in the code.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Kirill Reshke
Date:
Subject: Re: Add SPLIT PARTITION/MERGE PARTITIONS commands
Next
From: Roman Khapov
Date:
Subject: Re: Additional message in pg_terminate_backend