| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Orphaned records in pg_replication_origin_status after subscription drop |
| Date: | 2025-12-22 05:24:18 |
| Message-ID: | CAA4eK1LCgre6=L+WnNUJacpwmtJizSpuCUyrFbi_2ox3TX=REQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Dec 22, 2025 at 4:31 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Sat, Dec 20, 2025 at 02:55:15PM +0530, Amit Kapila wrote:
> > 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.
>
> ReplicationOriginNameForLogicalRep() would generate the origin name as
> pg_suboid_relid, so we would always reuse the same origin name on
> restart as long as the subscription is not recreated, wouldn't we?
>
Yes. I had thought about if there is any way the relid or subid can
change in between the restart of tablesync worker but I can't think of
any. So, it sounds safe.
--
With Regards,
Amit Kapila.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2025-12-22 05:38:39 | Re: Logical Replication of sequences |
| Previous Message | shveta malik | 2025-12-22 05:12:33 | Re: Skipping schema changes in publication |