Re: Updated backup APIs for non-exclusive backups

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: Updated backup APIs for non-exclusive backups
Дата
Msg-id CABUevEzeCZkXpbRPArUoW8bqK=vsyk-ycKWsOGwE23NbKHTnaw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Updated backup APIs for non-exclusive backups  (David Steele <david@pgmasters.net>)
Ответы Re: Updated backup APIs for non-exclusive backups  (David Steele <david@pgmasters.net>)
Список pgsql-hackers
On Tue, Mar 22, 2016 at 5:27 PM, David Steele <david@pgmasters.net> wrote:
On 3/22/16 12:14 PM, Magnus Hagander wrote:
> On Tue, Mar 22, 2016 at 5:08 PM, David Steele <david@pgmasters.net
> <mailto:david@pgmasters.net>> wrote:
>
>     On 3/19/16 8:15 AM, Magnus Hagander wrote:
>
>     > I've attached an updated patch, which is rebased on current master and
>     > includes the oid fix.
>
>     Before doing a thorough review of this patch there are a few points I
>     would like to consider:
>
>     * I think it's really important to provide the stop time in some fashion
>     when using this new technique.  I would prefer a new column to be
>     returned from pg_stop_backup() but I could live with STOP TIME being
>     recorded in the label file.  STOP TIME should probably be included in
>     the label file anyway.
>
> 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.

Having an actual definition of that is kind of required before adding it :P
 
> Doing it in the backup label file is obviously a different target, where
> we might need to consider backwards compatibility, Should we?

Physical backups can only be restored in the same version so I'm not
sure why it would be a problem?  Do you mean for programs outside of
Postgres that are parsing this file?

Yes, I meant programs outside postgres.

--

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

Предыдущее
От: David Steele
Дата:
Сообщение: Re: Updated backup APIs for non-exclusive backups
Следующее
От: David Steele
Дата:
Сообщение: Re: amcheck (B-Tree integrity checking tool)