Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pWruo-0006x2-3W for pgsql-hackers@arkaria.postgresql.org; Tue, 28 Feb 2023 04:48:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pWrum-0003Pk-V7 for pgsql-hackers@arkaria.postgresql.org; Tue, 28 Feb 2023 04:48:36 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pWrum-0003Pb-Jj for pgsql-hackers@lists.postgresql.org; Tue, 28 Feb 2023 04:48:36 +0000 Received: from mail-pf1-x434.google.com ([2607:f8b0:4864:20::434]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pWruj-00010P-1y for pgsql-hackers@lists.postgresql.org; Tue, 28 Feb 2023 04:48:36 +0000 Received: by mail-pf1-x434.google.com with SMTP id b20so4934842pfo.6 for ; Mon, 27 Feb 2023 20:48:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1677559711; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=JDpBWfyeRfE7/Sysv7FXNcPbu8lE5h3fM8ECQUtfQW4=; b=VVOfzkVarviEVDIzeXlr1zlCSCUlyRTDEnVU4w1CqvWjmpl+7aCOtI5oEW4YNcQ5Ni eUgTDkJmhrcV0F9nnI1oBspIcvETAq3cENO3YGNGqVMKQ4j8HBh4B91hsP2C/jZjgoDj Gmv/HC9hN/nx/mQYu19ibsp7X6xi9jzpGBeHEFfmT4vdGeCTSkE3V84Tz8xHV/8pL0DG pfquRo2U4/ZAV7TZrcHMDnhpy2I4MvF7OVu5s6XxYx7wkcca5GBwrPIp5U9pyOho81me UbsJlsNN1Vq7179Q4vc9qTXSn2NN4RsDYjCIVyUZheeg401NOOwkmfKDFujwnzfXBmIm WZ5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677559711; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=JDpBWfyeRfE7/Sysv7FXNcPbu8lE5h3fM8ECQUtfQW4=; b=iJRuPgMQDL3pH+ZBc2S3eU0nmDqtT8UC1eoS9Seqzb/g6iBDZj/ubvhSDVdqFMLk+2 TD7mLQSkpwCPq8BS5D4bhiwPq55/Xekh6oTTtxKyj1/iK1YgIX1T90l75tWkZpTN/Psz pWMln84G0pmq1JFkrh4UPopcYWxhExC9H4d6xw4rU1VgNhPCf+UI8rOVBJ20U5hOp9dI Ur1QC+JSYaJDA7748XW5x7OcpPxgA7Fh75LlY/iMN9qN/L54dNIcjIv4I5A0KQ3kbAr8 TpbsijJT7uC3YuYKWe+988E86DTVRIYn9vFKDZRA+IQz1imfvDEWhGGXstVJHPyp67Q4 rQUA== X-Gm-Message-State: AO0yUKUAejW9xLCjNINDMVfUtULfvOILNLCSKD9lrgp24FMNd+Fgo+WK bA5eIdeNS1QXv2U+t4BW60I= X-Google-Smtp-Source: AK7set/evNVnereDqNV+NluQflhNZDZA+7Xb5yR+UkA/dK/uKhh5p97WXMYRoNukO/IZAh7pG3DY9Q== X-Received: by 2002:aa7:96c9:0:b0:5a9:c682:831d with SMTP id h9-20020aa796c9000000b005a9c682831dmr1550324pfq.13.1677559710705; Mon, 27 Feb 2023 20:48:30 -0800 (PST) Received: from jrouhaud (2001-b011-1005-9ee4-e911-ddbc-809d-c2f2.dynamic-ip6.hinet.net. [2001:b011:1005:9ee4:e911:ddbc:809d:c2f2]) by smtp.gmail.com with ESMTPSA id y24-20020a62b518000000b005a8b4dcd21asm5197137pfe.15.2023.02.27.20.48.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Feb 2023 20:48:29 -0800 (PST) Date: Tue, 28 Feb 2023 12:48:27 +0800 From: Julien Rouhaud To: Amit Kapila Cc: pgsql-hackers@lists.postgresql.org Subject: Re: pg_upgrade and logical replication Message-ID: <20230228044827.u5surqffpytcewq3@jrouhaud> References: <20230219000109.bohkpeoej7kariku@jrouhaud> <20230220070737.4y3xialppl3imcgz@jrouhaud> <20230222064318.t5cstjbjpef3uboi@jrouhaud> <20230226030518.q6tggrid2vacmvlb@jrouhaud> <20230228022548.zuzqyu33dbv5ppyx@jrouhaud> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Feb 28, 2023 at 08:56:37AM +0530, Amit Kapila wrote: > On Tue, Feb 28, 2023 at 7:55 AM Julien Rouhaud wrote: > > > > > > The scenario I'm interested in is to rely on logical replication only for the > > upgrade, so the end state (and start state) is to go back to physical > > replication. In that case, I would just create new physical replica from the > > pg_upgrade'd server and failover to that node, or rsync the previous publisher > > node to make it a physical replica. > > > > But even if you want to only rely on logical replication, I'm not sure why you > > would want to keep the publisher node as a publisher node? I think that doing > > it this way will lead to a longer downtime compared to doing a failover on the > > pg_upgrade'd node, make it a publisher and then move the former publisher node > > to a subscriber. > > > > I am not sure if this is usually everyone follows because it sounds > like a lot of work to me. IIUC, to achieve this, one needs to recreate > all the publications and subscriptions after changing the roles of > publisher and subscriber. Can you please write steps to show exactly > what you have in mind to avoid any misunderstanding? Well, as I mentioned I'm *not* interested in a logical-replication-only scenario. Logical replication is nice but it will always be less efficient than physical replication, and some workloads also don't really play well with it. So while it can be a huge asset in some cases I'm for now looking at leveraging logical replication for the purpose of major upgrade only for a physical replication cluster, so the publications and subscriptions are only temporary and trashed after use. That being said I was only saying that if I had to do a major upgrade of a logical replication cluster this is probably how I would try to do it, to minimize downtime, even if there are probably *a lot* difficulties to overcome.