Re: Recovery tools
От | Tom Lane |
---|---|
Тема | Re: Recovery tools |
Дата | |
Msg-id | 7609.1050330366@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Recovery tools (mlw <pgsql@mohawksoft.com>) |
Ответы |
Re: Recovery tools
|
Список | pgsql-hackers |
mlw <pgsql@mohawksoft.com> writes: > Just suppose that all the log files are gone, and the only thing left is > some of the files in the /data directory. Is there any way to scan this > data and dump it to a file which could subsequently be used with a "COPY > FROM STDIN" on a new database? There aren't separate tools, and I'm not sure there could or should be. What I'd do in that situation is:* pg_resetxlog to get a minimally valid xlog* if clog is missing, gin up files containing0x55 everywhere (to make it look like every transaction has committed --- or put 00 everywhere if you'd ratherassume that recent transactions all aborted)* start postmaster, look around, fix problems until I can pg_dump. AFAICS, you can make tools that work at the page/item level (like pg_filedump, see http://sources.redhat.com/rhdb/), but there is hardly any scope for doing anything intermediate between that and a full postmaster. There's no hope of decoding the contents of a tuple without access to the table's tuple descriptor, which means you need most of the system catalog mechanisms; plus you'd need the I/O routines for the datatypes involved. Might as well just use the postmaster as your data inspection tool. regards, tom lane
В списке pgsql-hackers по дате отправления: