| 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
| 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/? |