Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Tom Lane wrote:
>> You might be able to fix this by doing a fresh initdb (targeting some
>> other location for the data directory, of course, but being careful
>> to use the exact same Postgres version) and then copying the
>> global/pg_filenode.map file out of that data directory and into your
>> broken one. This would only work if you've never done a VACUUM FULL on
>> any of the shared catalogs in the existing data directory, so it's far
>> from guaranteed to work; but it's worth a try.
> It's relatively easy to identify the files corresponding to each
> catalog, even when they have been mapped; just pg_filedump the files
> until you find ones that match the expected number of attributes, and
> disambiguate based on which attributes have HEAP_VARWIDTH and such.
> Then you just need to cp the right files to the default names using the
> default map created in the freshly initdb'd cluster.
Yeah, but that's getting past the level of what I'd expect an average user
to be able to do. If the data is valuable enough to justify that level of
effort, it'd be wise to hire a data recovery expert (such as yourself ;-)).
I'm suspicious that the "accidental damage" extended to more than
just global/pg_filenode.map. If it was really something more like
"find -name '*.map' | xargs rm", it would definitely be into professional
recovery territory, IMO.
regards, tom lane
