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
|
Список | 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 по дате отправления: