Re: Recovery target 'immediate'
От | Tom Lane |
---|---|
Тема | Re: Recovery target 'immediate' |
Дата | |
Msg-id | 10163.1366984128@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Recovery target 'immediate' (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: Recovery target 'immediate'
Re: Recovery target 'immediate' |
Список | pgsql-hackers |
Magnus Hagander <magnus@hagander.net> writes: > That said, maybe the easier choice for a *system* (such as v-thingy) > would be to simply to the full backup using pg_basebackup -x (or > similar), therefor not needing the log archive at all when restoring. > Yes, it makes the base backup slightly larger, but also much > simpler... As a bonus, your base backup would still work if you hosed > your log archive. It doesn't appear to me that that resolves Heikki's complaint: if you recover from such a backup, the state that you get is still rather vague no? The system will replay to the end of whichever WAL file it last copied. I think it'd be a great idea to ensure that pg_stop_backup creates a well defined restore stop point that corresponds to some instant during the execution of pg_stop_backup. Obviously, if other sessions are changing the database state meanwhile, it's impossible to pin it down more precisely than that; but I think this would satisfy the principle of least astonishment, and it's not clear that what we have now does. regards, tom lane
В списке pgsql-hackers по дате отправления: