Re: Recovery target 'immediate'

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Recovery target 'immediate'
Дата
Msg-id CA+TgmoZ8n2jEnZSe=KFMEMKCNyQkGD13g7rWm0VJyuCRXnC=yg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Recovery target 'immediate'  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Recovery target 'immediate'  (Magnus Hagander <magnus@hagander.net>)
Re: Recovery target 'immediate'  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
On Fri, Apr 26, 2013 at 10:05 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> Restore points are definitely the way to go here, this is what they
> were created for. Stopping at a labelled location has a defined
> meaning for the user, which is much better than just "stop anywhere
> convenient", which I found so frightening.
>
> It should be straightforward to create a restore point with the same
> name as used in pg_start_backup('text');
>
> pg_basebackup backups would need to use a unique key, which is harder
> to achieve. If we write a WAL record at backup start that would make
> the starting LSN unique, so we could then use that for the restore
> point name for that backup.
>
> If people want anything else they can request an additional restore
> point at the end of the backup.

I personally find this to be considerably more error-prone than
Heikki's suggestion.  On the occasions when I have had the dubious
pleasure of trying to do PITR recovery, it's quite easy to supply a
recovery target that never actually gets matched - and then you
accidentally recover all the way to the end of WAL.  This is not fun.
Having a bulletproof way to say "recover until you reach consistency
and then stop" is a much nicer API.  I don't think "stop as soon as
possible" is at all the same thing as "stop anywhere convenient".

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



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: libpq COPY handling
Следующее
От: Tom Lane
Дата:
Сообщение: Re: libpq COPY handling