Re: Per-table resync for logical replication subscriptions

At 2026-08-10 16:53:04, "Cagri Biroglu" <cagri(dot)biroglu(at)adyen(dot)com> wrote:
> Hi again,
> Thanks, and thanks for picking this up. I've registered it in the open
> CommitFest (PG20-2).
> Attached is v3, which is v2 rebased onto current master. Master removed
> Subscription.conninfo, so the one code change is that the mid-sync path
> now resolves the connection string with SubscriptionConninfo(sub). It
> does that at the point of use rather than up front, because the common
> case here is a relation in ready state, which needs no publisher
> connection at all. Nothing else changed, so your review of v2 still
> applies.

hi,
I have some review feedback on the v3-0001 patch.
The handling of inheritance tables and partition child tables with REFRESH TABLE seems incomplete; its current behavior is equivalent to the TRUNCATE ONLY syntax.
This could result in the following problems:
After executing REFRESH TABLE and before the tablesync worker completes synchronization, running SELECT * FROM parent will only return residual data from child tables, while rows residing directly in the parent table will be missing.
The partitioned parent table cannot be refreshed directly.
After the subscription is disabled, the states of child tables are not reset.
I originally expected data conflicts would arise, yet testing showed no critical data anomalies, and the data eventually became consistent.
Could you please assess whether this constitutes an issue that needs addressing?
Besides, I began reviewing this patch yesterday but have progressed rather slowly. The patch is now tagged "Waiting on Author". I apologize if this has held up your development work.

Best regards,

--

Yilin Zhang