Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1inIll-0007om-JZ for pgsql-docs@arkaria.postgresql.org; Fri, 03 Jan 2020 08:57:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1inIli-0000Oa-FI for pgsql-docs@arkaria.postgresql.org; Fri, 03 Jan 2020 08:57:18 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1inIlh-0000OT-39 for pgsql-docs@lists.postgresql.org; Fri, 03 Jan 2020 08:57:18 +0000 Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1inIld-00034x-Im for pgsql-docs@lists.postgresql.org; Fri, 03 Jan 2020 08:57:15 +0000 Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 38F7022189; Fri, 3 Jan 2020 03:57:12 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Fri, 03 Jan 2020 03:57:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=L1xvqvmZLfer5YdZUWutS7V4Nl+cuq6W/NvAV1wP/ AE=; b=jRgLhTRRk6D2HGLu4qsGBoKtPWMMUTYeCdsH96j1pIIy57JrLcuZ75dln TWuHNcVSFQpmCZrJc2unavZ+IemutYWYlGCZgzgIXDI+Id/owoKYTvKRT7w02EH/ ZzKBWr946mrr6Mig7fG8Z7oRnnbcRwEiLvM9JBCWIJAEp7O/FSRcxp3QzuELi2Qe 7WQIE5wR0K1Q89naezh+2DWvn4yiI0oTaIbu9PhXh2wEijGgnmJ36h+XNQzol2pr Jg/vCsHafm7K1qI6ftz4fL/7uxAq8ygmJKvP5IGNNzb/U6DFUnXDuEInDfXkHqh4 Xtp4zC5ZK560R2FMFtfcn7ih/hR6w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdegvddguddvvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefuvfhfhfhokffffgggjggtgfesthekredttdefjeenucfhrhhomheprfgv thgvrhcugfhishgvnhhtrhgruhhtuceophgvthgvrhdrvghishgvnhhtrhgruhhtsedvnh guqhhurggurhgrnhhtrdgtohhmqeenucffohhmrghinhepvdhnughquhgrughrrghnthdr tghomhenucfkphepleefrddvgeefrddukeejrddugeegnecurfgrrhgrmhepmhgrihhlfh hrohhmpehpvghtvghrrdgvihhsvghnthhrrghuthesvdhnughquhgrughrrghnthdrtgho mhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from april.pezone.net (p5df3bb90.dip0.t-ipconnect.de [93.243.187.144]) by mail.messagingengine.com (Postfix) with ESMTPA id 449AE8005A; Fri, 3 Jan 2020 03:57:11 -0500 (EST) Subject: Re: Link to "Upgrading a PostgreSQL Cluster" in Release Notes To: Vik Fearing , pgsql-docs@lists.postgresql.org References: <54c208b9-7e2c-6211-0ba0-ffb0429cf20b@2ndquadrant.com> From: Peter Eisentraut Organization: 2ndQuadrant Message-ID: <2cfbd3fe-85ef-d53b-53db-d93fbfe9f578@2ndquadrant.com> Date: Fri, 3 Jan 2020 09:57:10 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <54c208b9-7e2c-6211-0ba0-ffb0429cf20b@2ndquadrant.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2019-12-30 00:03, Vik Fearing wrote: > Following a complaint on IRC about the dearth of information on how to > migrate to a new major version in the release notes, the attached > trivial patch was determined to be sufficient for the OP. > > This patch applies to REL_12_STABLE.  I don't know how far it should be > backpatched (the OP was trying to upgrade to v10), and I didn't see any > place to put it for 13 and future versions. I think this change is sensible. But to what extent do we want to edit around in old release notes? Should we just keep it for PG13? I think we should also extend the blurb in the release notes to mention the option of using logical replication to upgrade. Otherwise, if you follow the link you propose, then one might think that logical replication upgrading is not applicable since only pg_dump and pg_upgrade were mentioned in the place the link came from. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services