From: Tom Lane <tgl@sss.pgh.pa.us>
To: ZongtianHou <zongtianhou@icloud.com>
cc: pgsql-admin <pgsql-admin@postgresql.org>
Subject: Re: how to upgrade with catalog change
In-reply-to: <6D98D845-DD56-43B7-A563-DCAFE61D655E@icloud.com>
References: <6D98D845-DD56-43B7-A563-DCAFE61D655E@icloud.com>
Comments: In-reply-to ZongtianHou <zongtianhou@icloud.com>
	message dated "Thu, 10 Sep 2020 17:15:07 +0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <181118.1599747377.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 10 Sep 2020 10:16:17 -0400
Message-ID: <181119.1599747377@sss.pgh.pa.us>
Precedence: bulk

ZongtianHou <zongtianhou@icloud.com> writes:
> I have a new version which merely add a new column (indnkeyatts int2) in=
 pg_index and can not be upgraded
> 1. if I add this column in middle by altering pg_index add column and dr=
op column in old version to match every column position in new version, th=
en can not started with new version, because there is dropped column info =
in old heap tuple header and it is accessed by hardcoded macro like Anum_p=
g_index_indkeynatts which cause column mismatch. And this can not be handl=
ed by deleting and inserting data again because database will be obsolete =
once the original data is deleted.
> 2. if this column is added to the end of pg_index( change macro in pg_in=
dex.h and pg_attribute.h), in this way I just need to add the new column a=
nd will not break old tuple, however,it can not be inited, does this colum=
n have to be added after column indnatts because fixed and variable length=
 thing?

> is there a simple way to just add this column and upgrade? and how does =
you implement it in pg_upgrade?

pg_upgrade never attempts to do direct surgery on catalogs.  The catalog
contents are transferred via pg_dump and reload, and only user tables are
moved physically.  Even if we cared to take the risk of doing something
like your suggestions above, it could only work for very trivial
cross-version catalog changes ... but such changes are frequently
far from trivial.  The SQL script generated by pg_dump is much
more portable.

			regards, tom lane