Re: more corruption - Mailing list pgsql-hackers

From Tom Lane
Subject Re: more corruption
Date
Msg-id 4940.963266903@sss.pgh.pa.us
Whole thread Raw
In response to Re: more corruption  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: more corruption  (Philip Warner <pjw@rhyme.com.au>)
Re: more corruption  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: libpq work
Next
From: Peter Eisentraut
Date:
Subject: Re: pg_backup symlink?