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'  (Simon Riggs <simon@2ndQuadrant.com>)
Re: Recovery target 'immediate'  (Bruce Momjian <bruce@momjian.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Substituting Checksum Algorithm (was: Enabling Checksums)
Следующее
От: Ashutosh Bapat
Дата:
Сообщение: Re: Functional dependencies and GROUP BY - for subqueries