Re: Orphaned records in pg_replication_origin_status after subscription drop
| От | Amit Kapila |
|---|---|
| Тема | Re: Orphaned records in pg_replication_origin_status after subscription drop |
| Дата | |
| Msg-id | CAA4eK1+-U-1V0VH02byaA3anUyS0VK3kO1SBKhYJcL-o0BMAyQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Orphaned records in pg_replication_origin_status after subscription drop (Masahiko Sawada <sawada.mshk@gmail.com>) |
| Список | 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 по дате отправления: