Re: Updated backup APIs for non-exclusive backups - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Updated backup APIs for non-exclusive backups
Date
Msg-id CABUevEzeCZkXpbRPArUoW8bqK=vsyk-ycKWsOGwE23NbKHTnaw@mail.gmail.com
Whole thread Raw
In response to Re: Updated backup APIs for non-exclusive backups  (David Steele <david@pgmasters.net>)
Responses Re: Updated backup APIs for non-exclusive backups
List 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 by date:

Previous
From: David Steele
Date:
Subject: Re: Updated backup APIs for non-exclusive backups
Next
From: David Steele
Date:
Subject: Re: amcheck (B-Tree integrity checking tool)