Re: Forcing current WAL file to be archived

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Forcing current WAL file to be archived
Дата
Msg-id 11661.1153843843@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Forcing current WAL file to be archived  (Simon Riggs <simon@2ndquadrant.com>)
Ответы Re: Forcing current WAL file to be archived  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
Simon Riggs <simon@2ndquadrant.com> writes:
> On Tue, 2006-07-25 at 11:31 -0400, Tom Lane wrote:
>> My point here is that forcing the current segment to archive is a
>> function of whatever your continuous-archiving process is, and it's
>> not necessarily tied to backups.  We should not prejudge when people
>> want that fairly-expensive function to be invoked.

> The point is until that last WAL file is backed up, the whole backup is
> useless. It isn't good policy to have a backup's value be contingent on
> some future event.

You are assuming here that the continuous archiving process is identical
to the WAL part of the base-backup process.  If what you want is an
identifiable self-contained base backup then you copy off the WAL files
along with the tar dump; there's no need to force a switch of the
current WAL file before you copy it.

I don't disagree that in many scenarios the switch is needful.  What I'm
saying is that we should provide a separately accessible function for it.
PG's PITR support is basically designed as a toolkit that lets you build
a PITR solution, not as do-everything, one-size-fits-all monolithic
functionality, and I want to stay in that spirit.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Forcing current WAL file to be archived
Следующее
От: Hannu Krosing
Дата:
Сообщение: Re: Forcing current WAL file to be archived