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 1vzXrh-0016Qk-1p for pgsql-hackers@arkaria.postgresql.org; Mon, 09 Mar 2026 10:29:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vzXrf-00FVoK-2l for pgsql-hackers@arkaria.postgresql.org; Mon, 09 Mar 2026 10:29:32 +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 1vzXrf-00FVoC-1T for pgsql-hackers@lists.postgresql.org; Mon, 09 Mar 2026 10:29:32 +0000 Received: from mail-pj1-x1035.google.com ([2607:f8b0:4864:20::1035]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vzXre-00000001GhX-0hmg for pgsql-hackers@lists.postgresql.org; Mon, 09 Mar 2026 10:29:31 +0000 Received: by mail-pj1-x1035.google.com with SMTP id 98e67ed59e1d1-359894e17b8so5594386a91.1 for ; Mon, 09 Mar 2026 03:29:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1773052169; cv=none; d=google.com; s=arc-20240605; b=CAG1PbaXPNGJAPxiadkd1kDyRnA9wu+05ZqDUbe/fKVFmsFPk058lRj0edN27hwn0+ TsaQw3G3Rj6WFKbpufhJ9LqFEYcMdapLEHLLmDF/NtTrAULWtnlwfuKGhYj1Tio6iNes 0rO6gWYIdFw2R/D0qO/ZmgOaWsJYRP83++hQDcikf10vzFSPQJEPq3Vn8fElUtXmKzT9 sEJOT/AZwK8MUHqErUYDZLPDKpopjuRIv4s6TWFF5HrSsYFBLIRnVIeW6jfLaSABx/No wlOuUp+o94tpVf93gPZhBmaIABg3Tcd1IeBY9ocd2yVdsoYGItrBsLv4YbHUvC/v6Sdk cGvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=dPwT9dNn0fwUC5ZDYVLZAEj6vNub3Lli5arIjRnDi8Q=; fh=7vafuI5+IzDeAlQ6Ytvv6xQYLD0iV633jj+uh7Lni2Q=; b=QVC9eXKm0I5dfYEv6QipmcBreV1QF7xPG4CL3JqZ2a7g3JUKB4SqCiSkp5Ho0ZUz01 K3mL9EFSb0AmdFhf39tHg6og3VMsVWWBp4nNZs0uGkHEgAHzH5yS9+ksPRXVeWEahH3Z UwfN55tUS5yopIibi0crYDEKnBFxtx6qi7GoqUpnJ3ulmz1VHycIuI9/woqMQedkr3ug Ddj0xp8UGZe4sNpznalooE32/B99SX5exegPwocbKrZt+umBP76WVwiddGq9Hg3FAkf/ BK+AVeq12NH0QUuBq+IlMTOhaCJ1jSUihJJQ7F3qmtRoUJZGn8tnl2fOou3YK1Vkot/U xXWQ==; 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=1773052169; x=1773656969; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=dPwT9dNn0fwUC5ZDYVLZAEj6vNub3Lli5arIjRnDi8Q=; b=ciV5xUgs/OL7g0oqsg6BCM8dfPksXkfS3g8bToEsFBcnJnMd+kq5pcjRi15uvt+uvA YNpoIq2yaC/H1pbJ4bIkkcQbVc5/y4/sAbAZZ0gqk0zSph1YeFOXKk7b9sD43OWlskxK /UXav5gzRIlwvFVy0YPBBxBrcpoDm2gC1YRZNqbzPrHqwvNCNjG0zkkqroHhSZ8cGPs/ txZpsph8mcjUrYjkjDEuOBVvxISL7HhVAw1YTonXff38f0KxcUeksk8pDy8hDKSWRXT2 6LEKZI87CE/Jdmn+Vwccj+qQO6j31nr0IXhU+rFD7CSomTccYtnSvR0HwxE+sMLBzad7 Hrug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773052169; x=1773656969; h=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=dPwT9dNn0fwUC5ZDYVLZAEj6vNub3Lli5arIjRnDi8Q=; b=KOS58vUXSNQKcYZNbPdW03DrL/gxyBvrJKN9w0LaE2VHVmEbHOsjhXVT7Z1zsEwFIP SxDZZnF3xUDZ/4FTN+pizJCGDMb+3Qauz5Oy4nRiVOveTy+WQfDmQnANhO/tikFn1PhB aPb+V14ne0ieuoFhYp3THuRhWfsuDYVtGi2rXQ1/mGpsJlllODtTpcBmycYKr5/nhVB6 tyRBEwm1pvpZdUpOo3tqxkehDq1c14Ht71PisEEWj/jp9rdZTu3fyFzyh7TswZU6vT13 tZoZvr7+1hqczayYJVcTFqAk9NTSsjKIMypdAMOpcGj/vGBQXJzdN8rDWochCTYoQE6k qzZQ== X-Forwarded-Encrypted: i=1; AJvYcCVNfPczpzFoyzDz2s84GWYzyUS86RGfQVAVVMS5WlELv5jOqHFpFVNhou+MvfBcq53nFST229cFLsQEF1yu@lists.postgresql.org X-Gm-Message-State: AOJu0YyhwdKrJeRE21mvQTIJ2NDyc5LjmnVp5Ulk+PBk5AaRORIFOOLo U8k70uO6FagB6Bw/o597nnlZ9oIviP0jiGP/qjcpuEQQ+fZuFuQsxFLtuszN2r4pTAH4fBjd2Ml fvfefY6RHtuQaOkzBgloVl8RUloIrZMA= X-Gm-Gg: ATEYQzzjUmZUOEmVLtX+8byv4TUd9CmXYM1MqfQ/wZNs8hEbXNvfVFZcQmRdGO9q6xI Mtt4CHC7+rkyTNkrsaz2q+TR1aVq4EvDJyNj0anadpjCJWBNebTqk5xoM0d70pSLqRn/gNuKucr pGHOadGVPmtAE72jwokht9uJ9h8GCrSrfTQA7Dc3UGKnnk9LNaYVrXQueV4cezECJxI+7IikebG 1nu3nesX3g1E642806Y4CjZnNrlIOaZaY16e9SWoKHHyezO0htPDYsfbFTIq/4zgtm0qMLdGHbB xQEm2sKL8Fkw3lKVue2URfyjMXN8if98aDlI8Nz9yYQizDYiLw8vvA== X-Received: by 2002:a17:90a:c2c3:b0:343:7714:4ca8 with SMTP id 98e67ed59e1d1-359be283138mr10487570a91.15.1773052169289; Mon, 09 Mar 2026 03:29:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Mon, 9 Mar 2026 15:59:15 +0530 X-Gm-Features: AaiRm53dgzAj9MUygczA6jee1yyn0AGaK1EB26zLVxwn5nRNN_ylUA9U9x6c34s Message-ID: Subject: Re: [PATCH] Support automatic sequence replication To: "Hayato Kuroda (Fujitsu)" Cc: "Zhijie Hou (Fujitsu)" , Ajin Cherian , Ashutosh Sharma , PostgreSQL Hackers , Amit Kapila , shveta malik Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Few comments for 0002: 1) + /* + * Allow synchronization if the remote sequence data has a more recent + * LSN than the local state, or if no local LSN exists yet. + */ + if (!XLogRecPtrIsValid(local_page_lsn) || + local_page_lsn < seqinfo->page_lsn) + return COPYSEQ_ALLOWED; /* * Skip synchronization if the current user does not have sufficient * privileges to read the sequence data. @@ -384,6 +418,40 @@ validate_seqsync_state(LogicalRepSequenceInfo *seqinfo, Relation sequence_rel) if (!GetSequence(sequence_rel, &local_last_value, &local_is_called)) return COPYSEQ_INSUFFICIENT_PERM; Shouldn't the 'COPYSEQ_INSUFFICIENT_PERM' check be the first one, else we may end up allowing the copy due to the first check even if the user has no privileges? Or let me know if I am missing something here. 2) + ereport(WARNING, + errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE), + errmsg("skipped synchronizing the sequence \"%s.%s\"", + seqinfo->nspname, seqinfo->seqname), + seqinfo->increment + ? errdetail("The local last_value %lld is ahead of the one on publisher", + (long long int) local_last_value) + : errdetail("The local last_value %lld is behind of the one on publisher", + (long long int) local_last_value)); This error message and DETAIL might not be very clear to the user. IMO, it may not be easy for the user to deduce that a sequence is descending and thus it being "behind" is the reason for skipping synchronization. Shall we update ERROR msg to say ascending/descending ERROR: skipped synchronizing ascending sequence ERROR: skipped synchronizing descending sequence Since we use descending/ascending in sequence doc many times, I feel it is okay to use it in ERROR messages too to give more clarity. Thoughts? 3) A sequence synchronization worker will be started - after executing any of the above subscriber commands. The worker will - remain running for the life of the subscription, periodically - synchronizing all published sequences. A sequence synchronization worker will be started + after executing ALTER SUBSCRIPTION ... REFRESH PUBLICATION + command. The worker will remain running for the life of the subscription, + periodically synchronizing all published sequences. Why have we changed this to mention REFRESH PUB alone responsible for starting worker? From user's point of view, even CREATE SUB (which has sequences) will also start the worker no? thanks Shveta