Hi,
On Wed, Jul 8, 2026 at 3:55 AM Cagri Biroglu <cagri.biroglu@adyen.com> wrote:
>
> here is the WIP patch for the disabled-subscription case.
> It adds:
>
> ALTER SUBSCRIPTION name REFRESH TABLE table_name
> [ WITH (copy_data = true, truncate = true) ]
>
> The command is subscriber-local: it resets just the named relation in
> pg_subscription_rel back to the initial sync state (optionally
> truncating the local copy first), so a tablesync worker re-copies that
> one table on the next enable, reusing the existing tablesync machinery.
> Publication membership and other tables are left untouched. As
> discussed, this first version requires the subscription to be disabled.
>
> The tests are included in the same patch: a TAP test at
> src/test/subscription/t/039_refresh_table.pl that
>
> - resyncs one drifted table on a two-node setup and confirms it
> matches the publisher again after re-enabling;
> - confirms only the targeted relation is reset (a sibling table is
> left in 'r' state);
> - checks the rejection cases: enabled subscription, table not in the
> subscription, a sequence, truncate without copy_data, and running
> inside a transaction block.
>
> The full src/test/subscription suite and the core regression tests pass
> with the patch applied.
>
> Open questions if this direction makes sense ,I would still like feedback on: the command spelling
> (REFRESH TABLE vs RESYNC TABLE), and whether the enabled-subscription
> case is worth doing as a follow-up (it needs the running apply worker to
> notice and re-read the reset relation state).
REFRESH TABLE is better to me. It's more consistent with the existing
commands such as REFRESH REQUENCES.
I've not looked at the patch in depth yet but I have a few comments:
I think it might be a good idea that the REFRESH TABLE command can
take multiple tables rather than one table.
---
Why does the REFRESH TABLE command require for the subscription to be
disabled while REFRESH PUBLICATIONS doesn't?
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
