Re: PITR Functional Design v2 for 7.5 - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: PITR Functional Design v2 for 7.5
Date
Msg-id 007001c4062c$ba8f7cf0$f3bd87d9@LaptopDellXP
Whole thread Raw
In response to Re: PITR Functional Design v2 for 7.5  (Andreas Pflug <pgadmin@pse-consulting.de>)
List pgsql-hackers
>Andreas Pflug
>> Josh Berkus wrote:
> >Related to the above, what I don't see in your paper or the proposed
API
> is a
> >way to coordinate full back-ups and WAL archiving.   Obviously, the
PITR
> >Archive is only useful in reference to an existing full backup, so it
is
> >important to be able to associate a set of PITR archives with a
> particular
> >full backup, or with some kind of "backup checkpoint".   I'm sure
that
> you
> >have a solution for this, I just didn't see it explained in your
> proposal, or
> >didn't understand it.
> >
>AFAICS there is a small detail
> missing so far.
> 
> When I'm doing a file level hot backup, I can't be sure about the
backup
> order. To be sure the cluster is in a consistent state regarding
> checkpoints, pg_clog must be the first directory backed up. If this
> isn't made sure, the situation could arise that the backed up clog
> version contains a checkpoint which marks a transaction completed that
> has been written to a file which was backed up earlier than the data
> write took place.
> 
> This could be insured by doing the backup in two steps; first backing
up
> pg_clog, and then the rest, restore being performed in the opposite
> order. 

Good spot. I'll add this to the design.

Will think more on the "backup checkpoint". Don't let me off the hook...

Best Regards, Simon 



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: PITR Functional Design v2 for 7.5
Next
From: Alexey Nalbat
Date:
Subject: Use "average field correlation per hard disk page" instead of global one?