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: | pgsql-hackers(at)hub(dot)org |
Subject: | Re: more corruption |
Date: | 2000-07-10 22:08:23 |
Message-ID: | 4940.963266903@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:
>>>> Yes, I had forgotten. The new table file names will make pg_upgrade
>>>> useless in the future.
>>
>> Hmm ... that's an implication I hadn't thought about. I wonder how much
>> work it would be to get pg_upgrade to rename table files. Be a shame to
>> throw pg_upgrade away after all the sweat we put into making it work ;-)
> Seems impossible. The physical file names are not dumped by pg_dump, so
> there is really no way to re-assocate the files with the table names.
> Looks like a lost cause.
Well, we'd need to modify the pg_dump format so that the OIDs of the
tables are recorded, but given that it doesn't seem impossible.
I suppose tablespaces might complicate the situation to the point where
it wasn't worth the trouble, though.
Given Vadim's plans for WAL and smgr changes, at least the next two
version updates likely won't be updatable with pg_upgrade anyway.
However, we've seen a couple of times recently when pg_upgrade was
useful as a recovery tool for system-table corruption, and that's why
I'm unhappy about the prospect of just discarding it...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2000-07-10 22:24:20 | Re: Slashdot discussion |
Previous Message | Tom Lane | 2000-07-10 22:03:30 | Re: libpq work |