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 1whOIE-000C91-0m for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Jul 2026 09:10:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1whOIB-006L52-1i for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Jul 2026 09:10:08 +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 1whOIB-006L4u-0e for pgsql-hackers@lists.postgresql.org; Wed, 08 Jul 2026 09:10:07 +0000 Received: from mail-pl1-x62a.google.com ([2607:f8b0:4864:20::62a]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1whOI9-00000000D8X-0NFI for pgsql-hackers@lists.postgresql.org; Wed, 08 Jul 2026 09:10:07 +0000 Received: by mail-pl1-x62a.google.com with SMTP id d9443c01a7336-2ccf2360620so1223955ad.3 for ; Wed, 08 Jul 2026 02:10:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1783501803; cv=none; d=google.com; s=arc-20260327; b=NVlATl2OJfrT5Odd06WsiaTHwcu0zp2f65YMUubnUd4uMFELS6Deub+VzXd8bOqBei 5JPJe/iurI8MqKFAAobWpBD7cPQ2cQgy9V5er2vw4b9EEE8n5HvemJkEXCdUl038gaHx mzEYhg3T5+1xO7YtUjhPXzbwRowKrV4uINxK+fIvYNV0+ZgWmTUN24Q78traAja+FOEj 5ZSRsasvWFcbOqwJ/Z1x/Bx5XPrAwitVWYrebNv3gQnUhhzhMFvsNjpPj5VZA1EBYmIk RHsHUaG2Tq+vwi9W9IX4r0pA3zRtAnwpk105unWQgZb+gH1UyPdHR8Xt4lwxbhpyrjg4 BbLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=fmajsUAGCU6aC+frlMF2wPRwJQEQIz7NizC+jElWTYA=; fh=sYY16WDpCNwCUllwycz/qJwLLZEjOrCIJdCzOaQrGy4=; b=TcRDFNnssCchC7PbffBbh2SWaSQ/rJA+kkSUCLrK5CMIt74CB5nrB4OqfM4eaDldC0 0S9TG/7yeJ56AehWVBLXgZmGiGy/kWzkX0U+PdULNNztZgks0auV4c8QBsjBkLmP3NKY 8LZ+dJYl6uqrmosKgydhG4/hQbRu1lHRlj6jKkJek4JuLorMkkzhIDMn45anKfp0EXsG toef/FuOM3erdxs+JDYbljU5rfaLWMAGyPnVxA8NQE1Wifsyf/4BWqhBVUEPyKGbr19p aVaSzEnpvwYFyqcdTjEL7wP4E6C/LIOgbh/e/4kiCFlgLXS84xKMuxBt3UvtXmkHMdRq O/PA==; 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=20251104; t=1783501803; x=1784106603; darn=lists.postgresql.org; h=content-transfer-encoding:content-type:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:from:to:cc:subject :date:message-id:reply-to:content-type; bh=fmajsUAGCU6aC+frlMF2wPRwJQEQIz7NizC+jElWTYA=; b=B/slSS0wGwqjb+cenVJp7wXw+m9ThOGxifnH0c2kG4/Uuv5wmcZogC68L+mj17+LqZ wXtSEPGIt8rjkdgEAEqJNN/bM6NfgUB1gXAE0zfbDVSzSiGBFPISLtzSNaS+RCOCJqAu IrGivdRa7t3hjWyvUF+J4lRNAo5s5GCdmtBeHeveiv+sA0YWEf7tVEYeR+I1aXD/oLMa 5QW5+4EJDydgNpUli+SI+YevUj6OkEHysb3Go0+2is3UO8M2lZHAoY5DP55NOCTy4oDX RSmrd5Q9qrpKuX/TQ/b6YZCa2m0NuyDtYqVgwjd5754OJKo2dVJsDCwumdiXy0kJkQf8 /nvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783501803; x=1784106603; h=content-transfer-encoding:content-type: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 :content-type; bh=fmajsUAGCU6aC+frlMF2wPRwJQEQIz7NizC+jElWTYA=; b=T4vUAYikRZM++ARNM8IiMQkmmkz1HEMS9gpx+2/vjVNBkez198FqDRAqK3iOogq/cd 6Q9mTOW13l/Jn2jpmha/rZaawfNWHsfyFU3v/Ik0sEeiOZMyGVMDu7iiGJt5IysPXsY7 FjS/3Y5YpUXUXAP6o9Gx0ugDi17MpRxc9+tLefsRyPjG0SoZzvrjXeIl3Z0navzda0j5 Q5T7BZUydxvccVntsfMSNhmP8/cMSe3Y3ZJcAJFRd61XFdnoT7UxKuDOTtfHzlMLs/q/ bgJ3q9izUefAe86UxXYPuXHTgihNLg1yYrGFlQk7RRuZiGkEqkhhVP2XJULdjEEDe9Xq 6M/w== X-Forwarded-Encrypted: i=1; AHgh+RrU3xZe9205NKdS5OB4xLdw6aWrjh5yEZRfyeLAV0y6VW48pQ+82ekWJ1myd+UXdRkQ+KLBenCylB1Cr16e@lists.postgresql.org X-Gm-Message-State: AOJu0YyySShkmqkI5nLF3+cReqPDojWw4aeHbJx1mxOZKHp7xnzoJhxU dk4jGhommix13gyIZTgCRSOIk0XyIHOwL96lGzGj5U9lHy1YCDckS3MxaSYJ/iG2bnGmcvniYzV vzcP5QpHi1isCVqT8DkrqsEYtd+xVwCE= X-Gm-Gg: AfdE7cl3wwT7JVp4pq5tC5VTQabvja9Cpp/+b+aBlI5UsADhpsldrrdGGOSN+xfUvMP /FhAHZFXGLkhqFWEDU9x+QDWIdhLNa/BM/C1oDjCHUTpW1aeHsCz1sDCiiGVoBb2Cuk+10Muk27 lk1/+GHJfU0zN6idK5LF7jeEa3ODdp3k3btvwcoZ2aWU6VYD3Il6fU7151SAE8J6cTnsx99kJyJ YMshwByHODpkQXShC0RW04hH9mwuaWs8o6ciC7LCBS5n4t1y3wEijF7r677RnvTqa8JyXMMx2+T iKqzjv+ILPktEUbtq6JOE4/cH2dlwNI8BMIniE/IBxkkj9G+CtWEnlo5UpKGalcD7stbNLRsTp4 = X-Received: by 2002:a17:902:ebcd:b0:2cc:ed57:c7c with SMTP id d9443c01a7336-2cced5724e1mr12935515ad.32.1783501803049; Wed, 08 Jul 2026 02:10:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Amit Kapila Date: Wed, 8 Jul 2026 14:39:51 +0530 X-Gm-Features: AVVi8CfF2VcosSVWtklEm4ylfBYfd1bXtYWdUBHlnoQQMct-5XnxqtShnPuxVzg Message-ID: Subject: Re: [PATCH] Preserve replication origin OIDs in pg_upgrade To: "Hayato Kuroda (Fujitsu)" Cc: shveta malik , Shlok Kyal , Ajin Cherian , Zsolt Parragi , "pgsql-hackers@lists.postgresql.org" 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 Wed, Jul 8, 2026 at 11:51=E2=80=AFAM Hayato Kuroda (Fujitsu) wrote: > > > For this reason, my inclination is to revert to the previous > > implementation, where we compare old_cluster.nsubs with > > max_active_replication_origins. But I'd like to hear what others think > > before we make this change. > > But if origin created by users (or any extensions) have already been trac= king the > Remote_lsn, they should be taken into account. If there are three enabled > subscriptions, two active user-created origins but the max_active_origin = is set > to three on the new node, the upgrading should fail. > Fair point but isn't it sufficient to check the tracked_origins rather than all origins? In docs of max_active_replication_origins, we say: "Setting it to a lower value than the current number of tracked replication origins (reflected in pg_replication_origin_status) will prevent the server from starting." which suggests here we should have a tight check of tracked_origins against max_active_replication_origins. > I prefer to preserve the current behavior of the patch, which compares > max_active_origin and total number of origins. It might cause the false-p= ositive, > but even now it can happen. E.g., if there was a subscription which has n= ever > been enabled. > I think it is possible that non-tracked origins (e.g for subscriptions that get enabled only after upgrade) could lead to ERROR after upgrade and starting the server but users can always increase max_active_replication_origins to accommodate that which she anyway needs to do even before upgrade. --=20 With Regards, Amit Kapila.