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 1wi454-000YtF-0A for pgsql-hackers@arkaria.postgresql.org; Fri, 10 Jul 2026 05:47:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wi452-00G6hF-0x for pgsql-hackers@arkaria.postgresql.org; Fri, 10 Jul 2026 05:47:21 +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 1wi451-00G6h6-3B for pgsql-hackers@lists.postgresql.org; Fri, 10 Jul 2026 05:47:20 +0000 Received: from mail-pj1-x1036.google.com ([2607:f8b0:4864:20::1036]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wi450-00000000bMJ-0CDn for pgsql-hackers@lists.postgresql.org; Fri, 10 Jul 2026 05:47:20 +0000 Received: by mail-pj1-x1036.google.com with SMTP id 98e67ed59e1d1-3825c406ffeso593685a91.0 for ; Thu, 09 Jul 2026 22:47:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1783662436; cv=none; d=google.com; s=arc-20260327; b=i2gf0V165djPiQybIzaX+Mzi6VkGWqiZ5sZncV0F9BAqypNUQZ7BWUaDVD36k3MMM5 QvoKM3x/ws8MUo1p92m4w2epTeVAq/3E58lTXH3S35LNy1PJ1zeGzCVenue56pQAVbD1 /QCrupGxIxCmApclOjMzvI4Yn6xEky/sTSBGxCtmNaFkLXM4D/+rymwHSK0hijhDzeM9 Me3h4SllBODZS4LBFbi6V3DmAK3oZWnZhOWilg3odwDLAVf3ih4vUVpI7zxQr3z2oU4/ x2N9aPY+CWEDE+aQWBOBl7f/ch+rJBDLi/awV/jv4Hch6WhFXEYvCRdrIzb1o90CTtyU URAQ== 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=QdifKZKSQIESEvssKBgLBmW9aMelkaNGpwFOkGi+Jxc=; fh=FcTyoo1IfwNL+Z1crS0I9zRY/ipC/OYUU0wNScKxzTQ=; b=eiTDAqOekMXiw9sX5v1E7JKp+dhF5QIv7vQc2NF0HOi78z3riv4i/IT/bjHgbTbfoP yrqdVHujOi6kXhfgk6GX7oqAtmkWieY0RsePARj2KzrZ4jOzZkSPxg0dRqt2XzxjU2NH oOQ3LDiYmCrrks1xiaqP8OixV4zaPjdt/8KIbizgOPgVa4IuyXbVbVxCLG1+IstU8P9Z TToU1QFJ6I+JdH+O3ml3q0rFcjmH5BUPYyAqRSYRHXUgl622iqcIdni8/lAHvVdHmuTK OCrZQS+NHYxATceOc6amG3goCo1FoDOZFt/nsFJCQzmrxLI5p2gu4sxIznwUhVgwWuj/ 2Nnw==; 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=1783662436; x=1784267236; 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=QdifKZKSQIESEvssKBgLBmW9aMelkaNGpwFOkGi+Jxc=; b=O/mJE6KXK6lXVnFPAdQsn6XnOhJKk9LxrjSjp8U66c6JDDbhEEBSeWSdV8YFXrf65x sKZrGFz4+P/DB5p9mYA0babnwbzIU+z/Lr7j37GvqvkVd5Dz/7WWBLvBL2vd8I4ZZv9E Igsn9aThFgz8xCgNSNeiH8qlycJUJPanIzwJzUWqk4pk8vN2f07r0JVpTiY57/L2GeXe OgCtPSULH/TGnFD6oYYBli9TLp91J4l+AqCPTOagJeMch6xX63FQy/MSBivGJaHaoH8c m3ZUvVlrbRuvdS3+ynPYG2+tNCwcI3DWF69Sz5KEEX7yP1XxWpTTwLwpdk22gkYH3mbx R+8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783662436; x=1784267236; 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=QdifKZKSQIESEvssKBgLBmW9aMelkaNGpwFOkGi+Jxc=; b=N0NB6c3hIq60byzusNm07VXWYe+mYbOrSQNR2xW4R8fg2sJ/vYrUPudSnudCavFPe5 cKV+ZddCxqz+/Rjy8uowasTe7VQB/f3ZEFOBJBmZoIeG/XEmntZVpGlktMLMtkaU3QjV P3iWsRJgxNksFI5iiQjNFGTWfDmflPuRi3zzvAZhfCA/s85suWv4gAan5D93jF45zdvR BUFlNfWg0rR/2o7iizB/NcYEVDTGLWOQxA23h6+sXDwEp2MXWBIIrTa/i+XkMAuuR8ij zjH82EJCAVNhAC8dGmCylSvClJE5O2tT2/0yCL6dVr4YF6Rmy+nPfR4GdUd46RNEWlfS MYaw== X-Forwarded-Encrypted: i=1; AHgh+Rpx3QrMQsljphnq1NW+cql1oOnUPcgCuvDb8AfPxb2skBBbofStgGtOM/TKY5XHidAymvIZxPLg+TRMPGSB@lists.postgresql.org X-Gm-Message-State: AOJu0YzZgqldS/gzGF42n7u1nUsc0PSGMOGgeCi1SqWhIFRpma93yyl4 dGNYWYyY/omxnbhXLSzioMM+r/hN9/CvgPl7Fa56kXDTp3NUHEmzPcC0erYTdJrFWIQVRoscylN 1FkmYcQrTOFiepATl53DKJBkhJ8eaIaE= X-Gm-Gg: AfdE7cmZcJLOVTHXeF6JVNSF2YpV7PvZJ1XTIk3XDX9KlOd4nWpePv8iEFblx8JxeM0 U/Yiz78SmUtAK753Feul3S3A5VGZVR+Cif8PasfY0GjTt2j5H4QbmVlE8zhSt4VjJ04RFjm6xSY H4sAOXOFb7q83BtJYH1Fv7DxVrPRB1RZ0JzLd0BJQNO1gnz4WzAQNsWa2UfqXyg/lujB4qTjTia e9YLiGy1Hgl0g4i+MQKDaNnLRbYaBXfx4y9SuJohqO2lrEPU+IkopTBesse1GBHVHZ3uUBSy35k wdIg0jvj/Gk7NhUuSAn66q2C+whYpPYfJ881ean8 X-Received: by 2002:a17:90b:3849:b0:387:41de:e8e with SMTP id 98e67ed59e1d1-38942f70ae8mr10211892a91.23.1783662436053; Thu, 09 Jul 2026 22:47:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Fri, 10 Jul 2026 11:17:03 +0530 X-Gm-Features: AVVi8CcykLUtEGd1j-RKFipUOGSRB7dRfdR0QYjYeJydTd-Tr3IiqsIODgbEEJI Message-ID: Subject: Re: [PATCH] Preserve replication origin OIDs in pg_upgrade To: Ajin Cherian Cc: Amit Kapila , "Hayato Kuroda (Fujitsu)" , Shlok Kyal , Zsolt Parragi , "pgsql-hackers@lists.postgresql.org" , 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, Jul 9, 2026 at 5:07=E2=80=AFPM Ajin Cherian wro= te: > > Thank you all for the comments. I have tried to address all the > comments. I am not responding to each of them here. Based on the > discussion above, I have retained the logic as mentioned by Shlok to > compare active origins against max_active_replication_origins. > > Attaching v11 with all comments addressed. > Thank You Ajin, a few trivial comments: 1) The new cluster must have max_ac= tive_replication_origins configured to a value greater than or equal to the number of - subscriptions present in the old cluster. + replication origins present in the old cluster. The new cluster must contain no replication origins. This needs change as well. 2) + "LEFT OUTER JOIN pg_catalog.pg_replication_origin_status os ON o.roident =3D os.local_id " We may as well replace 'LEFT OUTER' with 'LEFT'. The 'OUTER' is generally optional. But I leave it to you. (The doc says: 'The words INNER and OUTER are optional in all forms. INNER is the default; LEFT, RIGHT, and FULL imply an outer join.') 3) + * Also verify that the max_active_replication_origins configuration is + * enough for creating all the replication origins. We should change this too. 4) + * Compare against the number of active origins in the old cluster not the cluster not --> cluster, not 5) get_replication_origin_info: + if (PQntuples(res) !=3D 1) + pg_fatal("could not get the number of replication origins"); + cluster->nrepl_origins =3D atoi(PQgetvalue(res, 0, 0)); Can we please leave a blank line after pg_fatal for better readability. 6) + * with an entry in pg_replication_origin_status. This can be less than + * nrepl_origins, since an origin can exist without ever becoming A minor tweak suggestion: 'This can be less than ..' to: This count can be smaller than nrepl_origins because a replication origin can exist without ever becoming active 7) /* * get_subscription_info() * * Gets the information of subscriptions in the cluster. */ Originally this function was created to get number of subs and thus was named as 'get_subscription_info'. I am not sure if this name is still relevant. It is only getting 'retain_dead_tuples' info. Shall we modify the comment at-least. Suggestion: Determine whether any subscription has subretaindeadtuples enabled. thanks Shveta