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'
Re: Recovery target 'immediate' |
Список | 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 по дате отправления: