Re: Updated backup APIs for non-exclusive backups
От | David Steele |
---|---|
Тема | Re: Updated backup APIs for non-exclusive backups |
Дата | |
Msg-id | 56FA92D5.9060007@pgmasters.net обсуждение исходный текст |
Ответ на | Re: Updated backup APIs for non-exclusive backups (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: Updated backup APIs for non-exclusive backups
|
Список | pgsql-hackers |
On 3/22/16 12:31 PM, Magnus Hagander wrote: > On Tue, Mar 22, 2016 at 5:27 PM, David Steele <david@pgmasters.net > <mailto:david@pgmasters.net>> wrote:> > > Adding the stop time column should be a simple addition and I don't see > > a problem with that. I think I misunderstood your original request on > > that. Because you are just talking about returning a timestamptz with > > the "right now" value for when you called pg_stop_backup()? Or to be > > specific, just before pg_Stop_backup *finished*. Or do you mean when > > pg_stop_backup() started? > > What would be ideal is the minimum time that could be used for PITR. In > an exclusive backup that's the time the end-of-backup record is written > to WAL. In a non-exlusive backup I'm not quite sure how that works. I guess I was hoping that you would know. I fine with just getting the current timestamp as is currently done in do_pg_stop_backup(). It's not perfect but it will be pretty close. I thought some more about putting STOP_WAL_LOCATION into the backup label and I think this is an important step. Without that the recovery process needs to use pg_control to determine when the database has reach consistency and that will only work if pg_control was copied last. In summary, I think the patch should be updated to include stop_time as a column and add STOP_WAL_LOCATION and STOP_TIME to backup_label. The recovery process should read STOP_WAL_LOCATION from backup_label and use that to decide when the database has become consistent. Thanks, -- -David david@pgmasters.net
В списке pgsql-hackers по дате отправления: