Re: Per-table resync for logical replication subscriptions

From: Peter Smith <smithpb2250(at)gmail(dot)com>
To: Cagri Biroglu <cagri(dot)biroglu(at)adyen(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Per-table resync for logical replication subscriptions
Date: 2026-07-09 00:02:29
Message-ID: CAHut+Pue8auTiHrktbgh+rEJZ=Ac-WfT3SWYKnroV3uc4i99fQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jul 8, 2026 at 8:55 PM Cagri Biroglu <cagri(dot)biroglu(at)adyen(dot)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) ]
>
...
> 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).

(My feedback only about the syntax question)

As you said in the OP, this proposal is a bit like a table equivalent
of "ALTER SUBSCRIPTION sub REFRESH SEQUENCES".

IIRC we went through similar syntax debates when that command was
being developed.

Some alternatives were proposed [1]
ALTER SUBSCRIPTION sub RESYNC PUBLICATION SEQUENCES;
ALTER SUBSCRIPTION sub RESYNC SEQUENCES;

And, then more [2]
ALTER SUBSCRIPTION sub REPLICATE PUBLICATION SEQUENCES;
ALTER SUBSCRIPTION sub RESYNC PPUBLICATION SEQUENCES;
ALTER SUBSCRIPTION sub SYNC PUBLICATION SEQUENCES;
ALTER SUBSCRIPTION sub MERGE PUBLICATION SEQUENCES;

It went back and forth for a while...

Finally, I proposed [3] and gave some reasons for just having:
ALTER SUBSCRIPTION sub REFRESH SEQUENCES;

And that's where it ended up...

~~~

If your proposal is to proceed, then IMO it would be better to
continue the same pattern, avoiding introducing new keywords unless
absolutely necessary.

So, your v1 patch syntax "REFRESH TABLE" looked good to me. A similar
reasoning to "REFRESH SEQUENCES" [3] can be used to explain it.

======
[1] https://www.postgresql.org/message-id/CALDaNm30iA_N4Dfeyp__YdLnbm9oatw_%2BVyCfNfbQmZiS_ybCw%40mail.gmail.com
[2] https://www.postgresql.org/message-id/CAA4eK1JJUv2Kykb%3DJvdTzq%2BqDzkbD3m%2BYPAF6qz6Sm-qJ%2BwF8g%40mail.gmail.com
[3] https://www.postgresql.org/message-id/CAHut%2BPvOmCe2fO4LPwJtROierhGLtHY%2B%2B%2Br9PXF8%3DLLQ2m%3DAXw%40mail.gmail.com

Kind Regards,
Peter Smith.
Fujitsu Australia

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2026-07-09 00:14:49 Re: s/pg_attribute_always_inline/pg_always_inline/?
Previous Message David Rowley 2026-07-09 00:02:03 Re: s/pg_attribute_always_inline/pg_always_inline/?