Re: Recovering a deleted database problem
От | Tom Lane |
---|---|
Тема | Re: Recovering a deleted database problem |
Дата | |
Msg-id | 16101.1168012190@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Recovering a deleted database problem ("Andy Shellam (Mailing Lists)" <andy.shellam-lists@mailnetwork.co.uk>) |
Ответы |
Re: Recovering a deleted database problem
|
Список | pgsql-admin |
"Andy Shellam (Mailing Lists)" <andy.shellam-lists@mailnetwork.co.uk> writes: > Is it enough to simply have re-copied in the base/xxx directory from the > base backup, after the PITR recovery had completed (obviously any > changes made to that database since the base backup won't have been > restored but thankfully it's backed up nightly and doesn't change too > often :-) ) Well, I'd be a little worried about whether the base backup was self-consistent, but if it was taken at a time where the DB was idle then you can probably get away with this. > What I'll probably do is try to simulate the same process again on a > different machine to get myself a bit more familiar. Is there any other > situations you can think of where this may also be relevant, or is it > just when dropping a complete database? AFAIK the only operations that have non-rollbackable side effects are CREATE/DROP DATABASE and CREATE/DROP TABLESPACE. For any of these, you'd end up with inconsistent state if you try to stop replay just before the commit record. regards, tom lane
В списке pgsql-admin по дате отправления: