Re: Problem with PITR recovery

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Problem with PITR recovery
Дата
Msg-id 1113895582.16721.2096.camel@localhost.localdomain
обсуждение исходный текст
Ответ на Re: Problem with PITR recovery  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: Problem with PITR recovery  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Weirdess when altering serial column type
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Problem with PITR recovery