Re: Recovery target 'immediate'

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Recovery target 'immediate'
Дата
Msg-id CA+TgmoZnagO7HV64cjHZ8ndVsSk-MM6GJTBaR7ftZBzn5_ACXA@mail.gmail.com
обсуждение исходный текст
Ответ на Recovery target 'immediate'  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Ответы Re: Recovery target 'immediate'  (Fujii Masao <masao.fujii@gmail.com>)
Re: Recovery target 'immediate'  (Jaime Casanova <jaime@2ndquadrant.com>)
Список pgsql-hackers
On Thu, Apr 18, 2013 at 2:11 PM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
> I just found out that if you use continuous archiving and online backups,
> it's surprisingly difficult to restore a backup, without replaying any more
> WAL than necessary.
>
> If you don't set a recovery target, PostgreSQL will recover all the WAL it
> finds. You can set recovery target time to a point immediately after the
> end-of-backup record, but that's tricky. You have to somehow find out the
> exact time when the backup ended, and set it to that. But if you set it any
> too early, recovery will abort with "requested recovery stop point is before
> consistent recovery point" error. And that's not quite precise anyway; not
> all record types carry timestamps, so you will always replay a few extra
> records until the first timestamped record comes along. Setting
> recovery_target_xid is similarly difficult. If you were well prepared, you
> created a named recovery point with pg_create_restore_point() immediately
> after the backup ended, and you can use that, but that requires forethought.
>
> It seems that we're missing a setting, something like recovery_target =
> 'immediate', which would mean "stop as soon as consistency is reached". Or
> am I missing some trick?

You know, I've been wondering for years how you're supposed to do
this.  Huge +1 for adding something like this, if it doesn't exist
already.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: Inconsistent DB data in Streaming Replication
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Fix typo in contrib/hstore/crc32.c comment