Re: how to upgrade with catalog change

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



ZongtianHou <zongtianhou@xxxxxxxxxx> 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 column position in new version, then 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_pg_index_indkeynatts which cause column mismatch. And this can not 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 need to add the new column and will not break old tuple, however,it can not be inited, does this column 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






[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux