Date: Thu, 29 Jul 2021 14:19:17 -0400
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Dave Cramer <davecramer@gmail.com>
Cc: Bruce Momjian <bruce@momjian.us>,
	"David G. Johnston" <david.g.johnston@gmail.com>,
	Tom Lane <tgl@sss.pgh.pa.us>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: pg_upgrade does not upgrade pg_stat_statements properly
Message-ID: <202107291819.ewb44frhsac6@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CADK3HHLcVWSrRev1ahDKXpnKM2PGA2e3iebGUDMqAYQM3e4x+A@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/202107291819.ewb44frhsac6%40alvherre.pgsql>
Precedence: bulk

On 2021-Jul-29, Dave Cramer wrote:

> > I suggest "can be upgraded" rather than "should be upgraded" because
> > we're not making a recommendation, merely stating the fact that it is
> > possible to do so.
>
> Why not recommend it? I was going to suggest that we actually run alter
> extension upgrade ... on all of them as a solution.
> 
> What are the downsides to upgrading them all by default ? AFAIK if they
> need upgrading this should run all of the SQL scripts, if they don't then
> this should be a NO-OP.

I'm not aware of any downsides, and I think it would be a good idea to
do so, but I also think that it would be good to sort out the docs
precisely (a backpatchable doc change, IMV) and once that is done we can
discuss how to improve pg_upgrade so that users no longer need to do
that (a non-backpatchable code change).  Incremental improvements and
all that ...

-- 
Álvaro Herrera              Valdivia, Chile  —  https://www.EnterpriseDB.com/
"La libertad es como el dinero; el que no la sabe emplear la pierde" (Alvarez)