Re: [PATCH] Report changes discarded for relations not in the subscription

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

In response to

Browse pgsql-hackers by date

  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