Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vtJxR-00GVwC-2K for pgsql-hackers@arkaria.postgresql.org; Fri, 20 Feb 2026 06:25:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vtJwR-006iPM-1N for pgsql-hackers@arkaria.postgresql.org; Fri, 20 Feb 2026 06:24:43 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vtJwR-006iPC-01 for pgsql-hackers@lists.postgresql.org; Fri, 20 Feb 2026 06:24:43 +0000 Received: from mail-lf1-x12e.google.com ([2a00:1450:4864:20::12e]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vtJwO-00000000Jzw-0WkK for pgsql-hackers@lists.postgresql.org; Fri, 20 Feb 2026 06:24:42 +0000 Received: by mail-lf1-x12e.google.com with SMTP id 2adb3069b0e04-59e6253b16bso1925461e87.1 for ; Thu, 19 Feb 2026 22:24:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771568680; cv=none; d=google.com; s=arc-20240605; b=lpVj9Msns39QjKl5fDOu5CkhcbAqdqc9kgKo8j5QGwDIqupkhqPEmG0OZ25yGmo3B1 52/m4NStkgbNvgzm/oWi0p3vhmUuFbMUBL3JVnQ7Hvd8YfzsGWmGhlcTyfOrh/wTz9N6 aasZxuyLRjRMGOyoFBApzvlTqhbTMGQ+4PW0CFtGfRPm/xTuoGM/Rnz+y/m2rwQCGK5I V8rlMRopnMVGM+Gjj2FsotoWUsT2AINMmGiBjWr/Ymi3J+EweBLDidAVitfpbhrrvJET 6DODOFpsp8ia88jImI290lOOkS0KstSmZLh9fj6NfLYteYDX+2tzh3ExrbNGGAjoJf2P mTFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=LRz968fmrCs60M6R5I6ql5XpaQDF6g6o0sDkI6SzrYs=; fh=1oeCq4+kGPKow5w22FZYPpf/5zlTj9nCUUkBH6m9XBU=; b=h6LZ9S2T2TGUz2g4fcgtUspiKxz/ZvT753ICe3eULpK01lWVHkZWhbL3gyD2pySyOz MSh2k94GetbUi5dvY/M/ksfi2sS6TnbcO/lEnOfSG+ZbYed7jjCza1QK1EObOpKtUGgB b3IdDhzs69TNwtgf5GQZ/zxyoMz2uSDKt8IoTPfK7SOg2weMdX6zZvsPWLUgkT6rLSl9 beLAxFeJ/VgDi3fesygxjxePh8I1ilJw0FnZynvR2MAc9jmW8L65WxcgMX5/XiMjFiaj iIISJu7UlDhNpsVEcDyQ45fE1U28eHoAwHh90WKyiGiwBh8T1MGnMGfMqpfv6Qy4ExuI O26A==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771568680; x=1772173480; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=LRz968fmrCs60M6R5I6ql5XpaQDF6g6o0sDkI6SzrYs=; b=DF6aYkRiryQFEf0m1KoOaGBDkCAIP3sbtnlgAwnIDehEdTflrmgmehIqJ9WYtj2h7z ndpf0piJchKwRnjaY2Ov04OQFU3VloufqX3hqnDcHyBmbmyPIgYlmfL33p417/oda6Q2 eS6U0UmGZW8NVb8ImQEK2mESQdiQotmW55S3xk87FXuYuWQKuPdSB6MK8KwLB4Az2yHV bnm+uvJhbj9KT08oGIPj7bnkaJhxleGkh+z13HxF8sRgZcJp+AE2jm79OzNUaPKz8mDz 6S+qUnLRa5CcSqitk+OzvUBvfwpxNFaWdN99X+0r0DsGJveR92oV5yi2VlZi6OXgc7n6 Whfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771568680; x=1772173480; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=LRz968fmrCs60M6R5I6ql5XpaQDF6g6o0sDkI6SzrYs=; b=axdRUDnmmN16/xDrw1yZSvzr96/5QdzHYX2so/s1uoDQpZV6IFuMOyA0NO81dIjrD0 zwx/9Bt4Gtq3xMPAbaFM4zFXCPaQ/ahnvXJUn00un1HUhnYSP+N/h/SzYJLJCPL+RifZ H91Yixne4uvTxyQ91kqWyMmEp7qQBCwtgWT8boIpEXM290llXyEgdoV6lZ1HT8CdBmWR P2rDY2EsVfRSqWrxHgfROvHlCj71p4KX9MwU1MRRWnlUi/2Z2FzGPPndBjmmnqFQWScZ yfCcfx4cEo+bknnvR9dQTQzhVJsEgh7AWPt05OCGXVmDbo32yPpUus09aejjAF6JtzGH lRSw== X-Forwarded-Encrypted: i=1; AJvYcCW+dOcqsgRk2CBZfyZIvm6YnuFkEbkcurReIrnzQ8Sa5z8uR2e+om+VPZ0f2Ht0BAAnJ/6pfwLArUnZFhMw@lists.postgresql.org X-Gm-Message-State: AOJu0YwOzxvsRGSsZz+5frGmYrv0HJDsES93bRgOjnkP/vtYxIFdkG8t 4Tb36RLevrj6KXieBKQx0vNQu98Wo0+zvfST/P0MTtqHdOo8XKSg8pIjgWaAQs3g3AC8xSuVl1M aqd9eRINLRobV+YkTnUHlpG5HP63zg6Y= X-Gm-Gg: AZuq6aIrswu54p6peharat4vB4PiIzsK4mrjx9K9T8mlYS6Li4hGj2lQ3vIoFJ5Hyfv 9vbXW9k5ThI/ZaUBvyHxFrNI0EpjVPgn02RHPS61MHA8bJ/7TLXyr/mF1U+jUTqGsvJfuRv8uOt BrazEq1DshVeg62ptW1rIURaKwP/n0HH66AvVFHJiAzGyK69ZivH+z4OBeXocRrTDWPYOkXOJdJ SLw8iDr/ns/T95vvUIdLn9/JOleE8tM/frkO3Jg/4QmdyIRA38m1PomZlNmIWIXxdSUAnSWv2BR MW/PBFbhnJwD9NotlDvghupiNhcR+k1m6bQFyw== X-Received: by 2002:a05:6512:2349:b0:59e:648a:931c with SMTP id 2adb3069b0e04-5a030c16533mr186475e87.28.1771568679336; Thu, 19 Feb 2026 22:24:39 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dilip Kumar Date: Fri, 20 Feb 2026 11:54:22 +0530 X-Gm-Features: AaiRm53Hf_3YWmlz-pCyq7bkfH_6p2gCnh1WDGyACST9JWH0CExR09EEFlDmyI8 Message-ID: Subject: Re: [PATCH] Support automatic sequence replication To: Amit Kapila Cc: Ajin Cherian , PostgreSQL Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Feb 20, 2026 at 10:48=E2=80=AFAM Amit Kapila wrote: > > On Fri, Feb 20, 2026 at 10:11=E2=80=AFAM Dilip Kumar wrote: > > > > On Tue, Feb 3, 2026 at 9:18=E2=80=AFAM Ajin Cherian = wrote: > > > > > > Hello hackers, > > > > > > I'd like to propose an improvement to the sequence replication featur= e > > > that was committed in [1]. > > > > > > The current implementation synchronizes sequences during initial > > > subscription setup, but the sequence sync worker exits after this > > > initial sync. This means that as sequences advance on the publisher, > > > they drift from the subscriber values over time. Users must manually > > > run ALTER SUBSCRIPTION ... REFRESH SEQUENCES to resynchronize, which > > > requires monitoring and intervention. > > > > Thanks, Ajin, for the proposal. I am trying to think: what is the use > > case for automatically updating the sequence values? IIUC, the only > > use case for the sequence sync worker was when using logical > > replication for an upgrade; after the upgrade, you should have > > up-to-date values for the sequences. By adding an automatic update, > > are you targeting any new use case? > > > > If we are still targeting the same use case, I=E2=80=99d like to unders= tand > > how updating the value at specific intervals will improve the user > > experience. > > > > Even for an upgrade, to avoid large downtime, it would be better if > the subscriber has the latest values of sequences, so that during the > upgrade of the publisher, the subscriber can receive all client > requests. It is possible with the REFRESH SEQUENCES command as well > but in the worst case (when there are large number of sequences), it > can take much longer time. To clarify, here is the specific sequence synchronization use case I have in mind (major version upgrade with minimal downtime ) Setup: A PUB-SUB environment, both on PG17. Goal: Upgrade to PG18 with near-zero downtime. Upgrade: Run pg_upgrade on the Subscriber to move it to PG18. Replication: Logical replication continues from the PG17 Publisher to the PG18 Subscriber, including sequences. Sync: Wait for replication lag to hit near-zero and synchronize sequences. Cutover: Stop all traffic on the Publisher. Final Catch-up: Allow the PG18 Subscriber to catch up and perform a final sequence refresh. Switchover: Redirect all traffic to the Subscriber. In this major version upgrade scenario, the downtime is minimal (only while waiting for Final Catch-up). However, before the final switchover, the user must ensure all data and sequences are fully synced. They usually can't afford to wait for an automatic background sync, they need to force it using REFRESH SEQUENCES. My question is, does the proposed automatic sync allow us to avoid manual refreshes entirely in this process? Or is there another use case where the advantages of automation are more apparent? -- Regards, Dilip Kumar Google