public inbox for [email protected]
help / color / mirror / Atom feedFrom: Peter Smith <[email protected]>
To: Cagri Biroglu <[email protected]>
Cc: [email protected]
Subject: Re: Per-table resync for logical replication subscriptions
Date: Thu, 9 Jul 2026 10:02:29 +1000
Message-ID: <CAHut+Pue8auTiHrktbgh+rEJZ=Ac-WfT3SWYKnroV3uc4i99fQ@mail.gmail.com> (raw)
In-Reply-To: <CAA36msq+KWyQPqJjZ-+fzefdC_9GLLLYX1ZvR49-CQ7yMeB=0Q@mail.gmail.com>
References: <CAA36mso9zgvMVr4UNHMMAQyU-dQy33EqxjZ=yEDG8SAB6yYDJw@mail.gmail.com>
<CAA36msq+KWyQPqJjZ-+fzefdC_9GLLLYX1ZvR49-CQ7yMeB=0Q@mail.gmail.com>
On Wed, Jul 8, 2026 at 8:55 PM Cagri Biroglu <[email protected]> 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.g...
[2] https://www.postgresql.org/message-id/CAA4eK1JJUv2Kykb%3DJvdTzq%2BqDzkbD3m%2BYPAF6qz6Sm-qJ%2BwF8g%40...
[3] https://www.postgresql.org/message-id/CAHut%2BPvOmCe2fO4LPwJtROierhGLtHY%2B%2B%2Br9PXF8%3DLLQ2m%3DAX...
Kind Regards,
Peter Smith.
Fujitsu Australia
view thread (3+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Per-table resync for logical replication subscriptions
In-Reply-To: <CAHut+Pue8auTiHrktbgh+rEJZ=Ac-WfT3SWYKnroV3uc4i99fQ@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox