Re: Updated backup APIs for non-exclusive backups

From: David Steele <david(at)pgmasters(dot)net>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Marco Nenciarini <marco(dot)nenciarini(at)2ndquadrant(dot)it>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: Updated backup APIs for non-exclusive backups
Date: 2016-03-29 14:36:05
Message-ID: 56FA92D5.9060007@pgmasters.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 3/22/16 12:31 PM, Magnus Hagander wrote:

> On Tue, Mar 22, 2016 at 5:27 PM, David Steele <david(at)pgmasters(dot)net
> <mailto:david(at)pgmasters(dot)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(at)pgmasters(dot)net

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2016-03-29 14:50:09 Re: [PROPOSAL] Client Log Output Filtering
Previous Message Tom Lane 2016-03-29 14:20:21 Re: Re: [COMMITTERS] pgsql: Sync tzload() and tzparse() APIs with IANA release tzcode2016c.