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 1vxzy0-00HKmj-1K for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Mar 2026 04:05:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vxzxy-00FneF-2N for pgsql-hackers@arkaria.postgresql.org; Thu, 05 Mar 2026 04:05:39 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vxzxy-00Fne7-1Q for pgsql-hackers@lists.postgresql.org; Thu, 05 Mar 2026 04:05:38 +0000 Received: from mail-pf1-x42b.google.com ([2607:f8b0:4864:20::42b]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vxzxw-00000000j8V-2pxu for pgsql-hackers@lists.postgresql.org; Thu, 05 Mar 2026 04:05:38 +0000 Received: by mail-pf1-x42b.google.com with SMTP id d2e1a72fcca58-82418b0178cso4279241b3a.1 for ; Wed, 04 Mar 2026 20:05:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1772683534; cv=none; d=google.com; s=arc-20240605; b=GJNTS4Gu+uc75+cr6IYQ5O4H5CJ3Foe1Q2WFfRu2fC3OoUbM3ymeo/aHx9AMnN+0sZ OQxB7ktRKcdfbVlVNZ2AtjqKNxLbRovlmlmQ/+r6dDsygHVzL3h/Qp8d0VRXOSipUa85 fR8fHUF3DnOBVG7c4xd2hD7SHOr+JpWyw7l9BlrGT/HGydhTFCYvOOIB9H5P9tpWIg0Q l4usUMQ5AzVektOfkOJtFokKJhV/gfPDWLQrRr83k43T0wq35X1gc9aI3S7A/3Yfm7/w nTUk2i03XA1hMQAoPtFo3meqN1r4TRjErmWng7pM9txu9aAaStb2Law+mD4ELpbmSijF +pmw== 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=Ie2AgvLXGuD6Mj+/vB/C+c3WCwJJzVie9R//RoTrn4o=; fh=PZM94mTtAAOLwCPCo5KZ0NVEp5aXtPpLTR+OOHpyRqI=; b=GpxR0iTXJrkCVNt/BR7SR20zwAAKSOwS/61JDoD6wn+49F2j33fSKa+v9FEgBqvSWh 8IF7mettHOU2qliTbG2lr7jJQ1am5ugJDhjF+Bqs0WF/lXlGn7DcB7Dmb35tk+w8SfGS 2GrBzsJMQ4Yz2bLlicIXCrCDca9c2w6SaqVEE6CUm+uZnIin9xsH0yHMQ+ATGsgXNpcy +SkDZgeSnEgDoTDIBmFB8A8Co8pa17w5wHpWphfOBDuG9Ce8jb+mj8VqJiTbg1fAf8AO toe0yQFA5TZlHs29blszoal9zssoFVmAImndJ18nNYM66iPpxfng3Esd2pSuAAFcCg4/ Zkhw==; 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=1772683534; x=1773288334; 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=Ie2AgvLXGuD6Mj+/vB/C+c3WCwJJzVie9R//RoTrn4o=; b=PJBZ5Ap5XG+jdlb07FTWs+0uGYWQCDS2MVG9O0YNK2dbRHaKWBZFxEJYW3ixYzcJ4Z y0/tg94+bf/iKt7msVxZZDtac6WflJdXBLYNS6ntndYme0VyN4vcx3GkJvK6K4NCWOPp d+ENFSp/9cv/S0YaOH+No6uhhxPLs87+cxhdHEQKLbaA58tLtzIUcJOv+AqUnQxaOiTu fNXL1csil2k0kVwgHo05CkSSAKBWv4fMHP0pO3NuZtJajSu7bEjisTDqw3RMm22CObZd HQvAF2SEWnK+2CQytl+n1TPFqlU2m8g+LbwCaT1BBOxxQJIBbWkJ9WNR2KINfdsGKr3V uznA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772683534; x=1773288334; 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=Ie2AgvLXGuD6Mj+/vB/C+c3WCwJJzVie9R//RoTrn4o=; b=skrRqgRLqjtX/G38fJzjmSKDdNu18tmw4n+h9MlNSP5PGLR+gCt5vbjzOOtY51ScCc /eNm9cAeeuClAKE8wfJ7VMH7E/gr6W1k0wsb7Sr74zx2Svl0PslxSGcWPEjd4ioayI1M hu4m6RbvKqux+MK/tUM50CyvEMPsmNhXFqI9FwDfpRQo2B0rMlZJUQQScChnnjR7qLTP DjgMWKaAy8wyuklPFK8NA9l3l0ZH+ieG4J+Ffq4Z0hVdbhFJAk4oHgoXiZUYuwl0d7M0 YKAeTrJjJY70Dz/9dCxMUomLteqrhU6zFia+1BgK5et7o3avupuK9bg8wM8AZHZilk4y Hdvw== X-Forwarded-Encrypted: i=1; AJvYcCWtZhbHkP/ToZOPcML3yQtcQQUTqq2N+A6oOaghSuJumR/9RqqBbHnUtcvz3U+dRmyR0wuhTdaAEHqNUCkl@lists.postgresql.org X-Gm-Message-State: AOJu0YxwPzZZAFHjnqQ9c4ejPlMAt6/xZ+ytFslBqbyQsFLkaGuygdIi 2fKpUaMX3zdLeQ2jaFDCptdkwg72QXpjZcmJAZ4adUddLIT3c8bacIZOw6k0S1Iti2aph6ne46+ 2c2ZqHqUO11xWaBUkcAk3wXNXspzuIgs= X-Gm-Gg: ATEYQzzO9fWCk4Wo5iBq4BUZz2HDEnsK2Z5gX//X6OkMod4vtyXnnNb7Fr/MuFH2brD Ld+niiucaWuI0Sl4QmDwtmUfcwqDXzltm9Zl0YmozVktZPDJYVT/dg3xtgfHMAXBUdNi0SASapH M7Db/kZ5R3hnCidZeBskWh36H/HnThu6qE+u9iz3PL0YHTNetcxpY7kgZG7yUG2Ky/5ObbStXEG f8RPDacQSzkq0Rk6fQeUlCMJIVkIwvj2NR9Pcj79uKUbTy0b6kudJItWPoa4TChbXHRIau6wuG3 GwnFSdHmThFRr0SHQbzk/Lrw+rDGOkkMkWsED920Z9yNjKekG9htsw== X-Received: by 2002:a17:90b:164c:b0:32e:3829:a71c with SMTP id 98e67ed59e1d1-359a6a4a311mr4055280a91.16.1772683533750; Wed, 04 Mar 2026 20:05:33 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Thu, 5 Mar 2026 09:35:21 +0530 X-Gm-Features: AaiRm51iAvu5HHdfVzt8Ek4SDSQ1WsnvUYy54r5pF4tmlARZEZ8UNUFEVDRuZDI Message-ID: Subject: Re: [PATCH] Support automatic sequence replication To: "Zhijie Hou (Fujitsu)" Cc: Amit Kapila , Ajin Cherian , "Hayato Kuroda (Fujitsu)" , Ashutosh Sharma , PostgreSQL Hackers , shveta malik 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 Thu, Mar 5, 2026 at 8:16=E2=80=AFAM Zhijie Hou (Fujitsu) wrote: > > > Here is V10 patch set which addressed all comments. > Thank You. Please find a few comments on 001: 1) + /* + * Skip synchronization if the current user does not have sufficient + * privileges to read the sequence data. + */ + if (local_last_value =3D=3D 0) + return COPYSEQ_INSUFFICIENT_PERM; I don't think it is the right way to handle this. The local_last_value can be genuinely 0 for some cases and we may end up giving the wrong ERROR. Try this: CREATE SEQUENCE my_seq START WITH 0 INCREMENT BY 1 MINVALUE 0; And then set-up pub-sub. We get: 2026-03-05 08:57:39.591 IST [92281] WARNING: insufficient privileges on sequence ("public.my_seq") 2026-03-05 08:57:39.591 IST [92281] ERROR: logical replication sequence synchronization failed for subscription "subi1" Either we shall move back the acl check to the caller of GetSequence or pass the info of acl-check failure in a new argument or return value. 2) + /* + * For sequences in INIT state, always sync. Otherwise, for + * sequences in READY state, only sync if there's drift. + */ if (sync_status =3D=3D COPYSEQ_SUCCESS) - sync_status =3D copy_sequence(seqinfo, - sequence_rel->rd_rel->relowner); + sync_status =3D copy_sequence(seqinfo, sequence_rel); We shall add such a comment atop copy_sequence as well. I am unsure if we need it here or not. 3) + /* Sleep for the configured interval */ + (void) WaitLatch(MyLatch, + WL_LATCH_SET | WL_TIMEOUT | WL_EXIT_ON_PM_DEATH, + sleep_ms, + WAIT_EVENT_LOGICAL_SYNC_STATE_CHANGE); I don't think this wait-event is appropriate. Unlike tablesync, we are not waiting for any state change here. Shall we add a new one for our case? How about WAIT_EVENT_LOGICAL_SEQSYNC_MAIN? Thoughts? 4) + relstate =3D subrel->srsubstate; it will be good to move it just after below part: /* Skip if the relation is not a sequence */ 5) } + /* Check if there are any sequences. */ + has_subsequences =3D (seq_states !=3D NIL); One blank line before new change will improve readability. 6) ########## ## ALTER SUBSCRIPTION ... REFRESH PUBLICATION should cause sync of new -# sequences of the publisher, but changes to existing sequences should -# not be synced. +# sequences of the publisher. ########## # Create a new sequence 'regress_s2', and update existing sequence 'regres= s_s1' Last comment needs to be changed. Remove this please: 'and update existing sequence 'regress_s1'' thanks Shveta