| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Resurrecting pg_upgrade |
| Date: | 2003-12-14 23:02:37 |
| Message-ID: | 3313.1071442957@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Matthew T. O'Connor" <matthew(at)zeut(dot)net> writes:
>> [ pg_upgrade won't be able to change user table representation ]
> How limiting is the above? Does this mean that pg_upgrade will be
> rendered invalid if there is an on-disk representation change? Do we
> think we will make it from 7.4 -> 7.5 without on-disk changes? Do we
> think at this point most upgrades will be without on-disk changes?
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2003-12-14 23:09:33 | Re: ORDER BY and DISTINCT ON |
| Previous Message | Dennis Bjorklund | 2003-12-14 22:40:09 | Re: fork/exec patch |