Обсуждение: how to upgrade with catalog change

Hi, everyone

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 drop column in old version to match every column
positionin new version, then can not started with new version, because there is dropped column info in old heap tuple
headerand it is accessed by hardcoded macro like Anum_pg_index_indkeynatts which cause column mismatch. And this can
notbe handled 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_index.h and pg_attribute.h), in this way I just
needto add the new column and will not break old tuple, however,it can not be inited, does this column have to be added
aftercolumn 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?

Best Regards,
Zongtian

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 drop column in old version to match every
columnposition in new version, then can not started with new version, because there is dropped column info in old heap
tupleheader and it is accessed by hardcoded macro like Anum_pg_index_indkeynatts which cause column mismatch. And this
cannot be handled 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_index.h and pg_attribute.h), in this way I just
needto add the new column and will not break old tuple, however,it can not be inited, does this column have to be added
aftercolumn 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

Thanks very much, it seems that using pg_dump and reload is the standard and most safe way. Happy to get it.

Best Regards,
Zongtian

> On Sep 10, 2020, at 10:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> 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 drop column in old version to match every
columnposition in new version, then can not started with new version, because there is dropped column info in old heap
tupleheader and it is accessed by hardcoded macro like Anum_pg_index_indkeynatts which cause column mismatch. And this
cannot be handled 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_index.h and pg_attribute.h), in this way I
justneed to add the new column and will not break old tuple, however,it can not be inited, does this column have to be
addedafter 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
>
>