Re: sequencesync worker race with REFRESH SEQUENCES

On Mon, Jul 13, 2026 at 5:46 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> 2)
> The fix will solve the purpose. But I have a doubt for the check in
> copy_sequences(). Say a few sequences are already in the INIT state,
> and the subscription is then repointed to a pre-PG19 publisher. Would
> the apply worker keep launching the sequence sync worker, only for it
> to exit each time with this error of copy_sequences? Is my
> understanding correct? If so, is there a way to avoid launching the
> sequence sync worker altogether when connected to a pre-PG19
> publisher? We do have 'LogRepWorkerWalRcvConn' in the apply worker to
> check the version.
>

Good question. I think to handle the case you pointed and even REFRESH
SEQUENCES case, isn't it better to raise an ERROR when the user is
trying to point connection to a version prior to 19 and the subscriber
has sequences? For example, we do something similar retain_dead_tuples
parameter in AlterSubscription, see handling of
ALTER_SUBSCRIPTION_SERVER/ALTER_SUBSCRIPTION_CONNECTION->check_pub_rdt
in AlterSubscription().

One additional comment on 0001:
===========================
*
@@ -435,6 +435,19 @@ copy_sequences(WalReceiverConn *conn)
StringInfoData cmd;
MemoryContext oldctx;

+ /*
+ * Sequence synchronization relies on pg_get_sequence_data(), which is
+ * only available since PostgreSQL 19. Fail with a clear diagnosis
+ * instead of sending a query that the publisher cannot execute (or
+ * cannot even parse), which would otherwise make this worker exit with
+ * a confusing "invalid query response" error.
+ */
+ if (walrcv_server_version(conn) < 190000)
+ ereport(ERROR,
+ errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+ errmsg("cannot synchronize sequences for subscription \"%s\" because
the publisher is running a version earlier than PostgreSQL 19",
+ MySubscription->name));

I think it is better to move this check to the caller immediately
after making a connection to the publisher. Also, the second part of
the comment: "Fail with a clear diagnosis instead of sending a query
that the ..." appears redundant to me as the code is explicit about
the case.

--
With Regards,
Amit Kapila.