| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
|---|---|
| To: | vignesh C <vignesh21(at)gmail(dot)com> |
| Cc: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, shveta malik <shveta(dot)malik(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: sequencesync worker race with REFRESH SEQUENCES |
| Date: | 2026-07-21 04:44:24 |
| Message-ID: | CAA4eK1K377ATezBiAvTU13qNcJKxoT67xbxdt+78CobhG_SO5w@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jul 15, 2026 at 2:44 PM vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> On Wed, 15 Jul 2026 at 07:01, Hayato Kuroda (Fujitsu)
> <kuroda(dot)hayato(at)fujitsu(dot)com> wrote:
> >
>
> > 02.
> > ```
> > @@ -2142,6 +2145,12 @@ AlterSubscription(ParseState *pstate, AlterSubscriptionStmt *stmt,
> > * retain_dead_tuples.
> > */
> > check_pub_rdt = sub->retaindeadtuples;
> > +
> > + /*
> > + * If the subscription already has sequences, ensure the new
> > + * publisher is new enough to synchronize them.
> > + */
> > + check_pub_seq = HasSubscriptionSequences(subid);
> > ```
> >
> > HasSubscriptionSequences() can spend long time because it searches pg_subscription_rel
> > catalog linerly. Do you think we can do the deferrable approach? I imagined to
> > check the remote version first and then check the catalog if the version is prior
> > than PG 19. Or it might be more costly to check the remote version?
>
> If we do it that way, every ALTER SUBSCRIPTION CONNECTION or SERVER
> would connect to the publisher, even for subscriptions that don't have
> any sequences. At present, we only establish a connection to the
> publisher when it is actually required, such as when update_failover,
> update_two_phase, or check_pub_rdt is true. Establishing a connection
> to the publisher is not a lightweight operation. It involves creating
> a new connection, performing authentication, and incurring network
> round trips before we can determine whether the publication contains
> any sequences. In contrast, HasSubscriptionSequences() only performs a
> local catalog lookup on the subscriber to determine whether the
> subscription has any sequences, which is significantly cheaper.
>
I agree with this reasoning for not performing connection before
checking sequences. I think if we want to make
HasSubscriptionSequences() cheap then we can have an index on srsubid
in pg_subscription_rel or somehow track the presence of sequences at
pg_subscription level. The other idea to optimize is that for the
cases where we anyway need to form connection with the publisher, we
can defer checking the sequences. However, I feel changing the
connection string shouldn't be performed often enough to worry about
or adding additional complexity in code or adding more optimizations
for it.
--
With Regards,
Amit Kapila.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Srinath Reddy Sadipiralla | 2026-07-21 04:52:52 | Re: Fix "unexpected logical decoding status change" error; from concurrent logical decoding activation |
| Previous Message | Amit Kapila | 2026-07-21 04:35:54 | Re: sequencesync worker race with REFRESH SEQUENCES |