From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>, Hannu Krosing <hannu(at)tm(dot)ee>, mlw <pgsql(at)mohawksoft(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Upgrading rant. |
Date: | 2003-01-04 01:47:14 |
Message-ID: | 23902.1041644834@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> OK, taking up the pg_upgrade banner, I think there are two things
> missing from the current code:
> 1) schema awareness -- easily fixed with some code
> 2) need to creat clog files to match incremented xid
> I can do 1, and I think Tom can help me with 2.
I was just now wondering whether we really need to do that at all.
We're already vacuuming the user tables before we bring 'em over.
What if we VACUUM FREEZE them instead? Then there are *no* xids of
interest in the tables being brought over, and no need to screw around
with the xid counter in the new installation. That in turn would mean
no need to mess with its pg_clog files. I think we'd still need to
advance the xlog position past the old installation's xlog end, but we
have the tool for that (pg_resetxlog) already.
> Also, I think we make index format changes more frequently that Tom
> recollects. Tom?
Oh? Name one... not that they'd be a critical problem anyway, as we
could easily reconstruct indexes via REINDEX rather than moving them
over, any time we made such a change.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Copeland | 2003-01-04 02:11:17 | Re: Threads |
Previous Message | Bruce Momjian | 2003-01-04 01:36:42 | Re: Upgrading rant. |