From: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Resurrecting pg_upgrade |
Date: | 2003-12-15 02:28:34 |
Message-ID: | 3FDD1C52.8040903@familyhealth.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Per prior discussion, we will enforce some sort of limit on how often
> the representation of user tables/indexes can be changed. The idea will
> be to "batch" such changes so that you only have to do a dump/reload
> every N major releases instead of every one. In other words, pg_upgrade
> will work for most version upgrades but we reserve the right to
> occasionally make releases where it doesn't work.
>
> How large N will be in practice remains to be seen, of course, but I'd
> expect something on the order of 4 or 5.
>
> In theory pg_upgrade could be made to apply changes in user data
> representation, but I'm unconvinced that such a process would be a big
> improvement over dump/reload.
Will we now have to be careful to NEVER re-use OIDs in the system catalogs.
Chris
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-12-15 02:29:59 | Re: Resurrecting pg_upgrade |
Previous Message | Tom Lane | 2003-12-15 00:14:53 | Re: fork/exec patch |