Re: [HACKERS] Incrementally Updated Backup

Your patch has been added to the PostgreSQL unapplied patches list at:

http://momjian.postgresql.org/cgi-bin/pgpatches

It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.

---------------------------------------------------------------------------

Simon Riggs wrote:
>
> > On Tue, 2006-09-19 at 12:13 -0400, Tom Lane wrote:
>
> > Also, I'm not sold that the concept is even useful. Apparently the idea
> > is to offload the expense of taking periodic base backups from a master
> > server, by instead backing up a PITR slave's fileset --- which is fine.
>
> Good. That's the key part of the idea and its a useful one, so I was
> looking to document it for 8.2
>
> I thought of this idea separately, then, as usual, realised that this
> idea has a long heritage: Change Accumulation has been in production use
> with IMS for at least 20 years.
>
> > But why in the world would you want to stop the slave to do it? ISTM
> > we would want to arrange things so that you can copy the slave's files
> > while it continues replicating, just as with a standard base backup.
>
> You can do that, of course, but my thinking was that people would regard
> the technique as "unsupported", so I added a quick flag as a prototype.
>
> On Tue, 2006-09-19 at 12:13 -0400, Tom Lane wrote:
>
> > This patch has obviously been thrown together with no thought and even
> > less testing. It breaks the normal case (I think the above if-test is
> > backwards), and I don't believe that it works for the advertised purpose
> > either (because nothing gets done to force a checkpoint before aborting,
> > thus the files on disk are not up to date with the end of WAL).
>
> Yes, it was done very quickly and submitted to ensure it could be
> considered yesterday for inclusion. It was described by me as rushed,
> which it certainly was because of personal time pressure yesterday: I
> thought that made it clear that discussion was needed. Heikki mentions
> to me it wasn't clear, so those criticisms are accepted.
>
> On Tue, 2006-09-19 at 16:05 +0100, Heikki Linnakangas wrote:
> > Simon Riggs wrote:
> > > +
> > > + if (startupAfterRecovery)
> > > + ereport(ERROR,
> > > + (errmsg("recovery ends normally with startup_after_recovery=false")));
> > > +
> >
> > I find this part of the patch a bit ugly.
>
> Me too.
>
>
>
> Overall, my own thoughts and Tom's and Heikki's comments indicate I
> should withdraw the patch rather than fix it. Patch withdrawn.
>
> Enclose a new doc patch to describe the capability, without s/w change.
>
> --
> Simon Riggs
> EnterpriseDB http://www.enterprisedb.com

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +