Re: [ADMIN] Re: [SQL] Data recovery
От | Bruce Momjian |
---|---|
Тема | Re: [ADMIN] Re: [SQL] Data recovery |
Дата | |
Msg-id | 199906011728.NAA01606@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [ADMIN] Re: [SQL] Data recovery (wieck@debis.com (Jan Wieck)) |
Ответы |
Re: [ADMIN] Re: [SQL] Data recovery
|
Список | pgsql-general |
> > If you only have the data/base subdirectory, you will need to work > > harder; you'll have to regenerate the top-level files. I think if you > > get pg_shadow and pg_database right you will be OK. First, install and > > initdb to get a basic set of files. You will need to recall the old set > > of users (including their userIDs) in order to reconstruct pg_shadow. > > After you've done the createusers, issue a createdb for each old > > database (subdirectory of base/) so that they have entries in > > pg_database. Then, shut down the postmaster, blow away the contents of > > the base/ subdirectory and restore it from tape, and restart. I think > > it'll work... > > > > In any case it's critical to install the same Postgres version you > > were using. > > NO - this cannot work. He surely needs the entire data > directory because the information in the heap's relies on the > bits in data/pg_log. And that info (which XID's are > committed and which not) cannot be reconstructed from the > files - no chance. Very, very hard, but not impossible. If you update a row, and do a select on that row, the select updates the transaction status so the next select doesn't need to look at the pg_log table. What this means is that pg_log could probably be reconstructed from existing data, with just 'unselected' changes not appearing properly. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
В списке pgsql-general по дате отправления: