| From: | Hüseyin Demir <huseyin(dot)d3r(at)gmail(dot)com> |
|---|---|
| To: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [PATCH] Report changes discarded for relations not in the subscription |
| Date: | 2026-10-30 07:37:30 |
| Message-ID: | CAB5wL7b74bpW3KhKxY-8_+XsyGRudirBR5-HuVAgjnR1kR53kw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Hayato,
> > Dear Hüseyin,
> >
> > > I encountered an issue after a pg_upgrade of a subscriber instance.
> > > pg_subscription_rel came back empty, and the apply worker then discarded
> > > every incoming change while the replication origin and the publisher
> > > slot's confirmed_flush_lsn advanced past the discarded rows. Both ends
> > > durably recording the transactions as applied, with nothing in either log
> > > to say otherwise.
> >
> > To confirm, what was the datasabse version of old and new cluster? 9a17be1e2
> > allowed to migrate the content of pg_subscription_rel catalog[1]. It means it's
> > unexpected behavior and must be fixed if old one is PG17+.
> >
> > [1]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=9a17be1e2
> >
> > Best regards,
> > Hayato Kuroda
> > FUJITSU LIMITED
Created a v2 patch and let me summarize the problem.
If a table is added to a publication (ALTER PUBLICATION ... ADD TABLE)
and ALTER SUBSCRIPTION ... REFRESH PUBLICATION is not run on the
subscriber, the table has no pg_subscription_rel row. The apply
worker drops every change for it in should_apply_changes_for_rel(),
with no log message, no conflict and no statistics counter. The
publisher is told the changes were applied, so the origin and the slot
move past them. Rows only reappear if the table is later added and
copied again.
Report the skip from should_apply_changes_for_rel():
- relation not in the subscription: LOG, with a hint to run ALTER
SUBSCRIPTION ... REFRESH PUBLICATION
- relation not yet synchronized: DEBUG2
Each relation is reported once per sync state for the lifetime of the
apply worker, tracked in LogicalRepRelMapEntry, since this gate is
reached once per change. A restarted worker reports again.
Example:
LOG: skipping changes for relation "public.tab_4" in subscription "tap_sub"
DETAIL: The relation is not part of the subscription.
HINT: Use ALTER SUBSCRIPTION ... REFRESH PUBLICATION to add it.
No behavior change beyond the new messages. The patch includes TAP
tests for the apply worker (024_add_drop_pub.pl) and for a parallel
apply worker (015_stream.pl). I intend this for master only.
Regards,
Demir.
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-log-unapplied-changes-for-non-ready-relations.patch | application/octet-stream | 10.9 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Henson Choi | 2026-10-30 07:40:38 | [DEPARSE] Parameters in SQL-standard function bodies do not read back |
| Previous Message | ZizhuanLiu X-MAN | 2026-10-30 07:31:16 | Re: Optimize mergejoinscansel() by avoiding redundant computations |