Re: Problem with PITR recovery - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Problem with PITR recovery
Date
Msg-id 1113895582.16721.2096.camel@localhost.localdomain
Whole thread Raw
In response to Re: Problem with PITR recovery  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Problem with PITR recovery
List pgsql-hackers
On Mon, 2005-04-18 at 21:25 -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > Simon Riggs <simon@2ndquadrant.com> writes:
> > > The wal file could be truncated after the log switch record, though I'd
> > > want to make sure that didn't cause other problems.
> > 
> > Which it would: that would break WAL file recycling.
> 
> Good point. I don't see non-full WAL archiving as a problem for the
> backup or shutdown, but I do see an issue with doing archives every X
> seconds.  If someone sets that really low (and someone will) we could
> easily fill the disk.  

The disk would only fill if the archiver doesn't keep up with
transmitting xlog files to the archive. The archive can fill up if it is
not correctly sized, even now. Switching log files every N seconds would
at least give a very predictable archive sizing calculation which should
actually work against users sizing their archives poorly.

> However, rather than do it ourselves, maybe we
> should make it visible to administrators so they know exactly what is
> happening and can undo it in case they need to recover, something like:
> 
> 
>     archive_command = 'gzip <%p >%f'
> 
> so the compression is done in a way that is visible to the
> administrator.

As long as we tell them there's more than one way to do it. Many tape
drives offer hardware compression, for example, so there would be no
gain in doing this twice.

Best Regards, Simon Riggs



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Weirdess when altering serial column type
Next
From: Simon Riggs
Date:
Subject: Re: Problem with PITR recovery