Re: Forcing current WAL file to be archived
От | Simon Riggs |
---|---|
Тема | Re: Forcing current WAL file to be archived |
Дата | |
Msg-id | 1153841842.2592.579.camel@holly обсуждение исходный текст |
Ответ на | Re: Forcing current WAL file to be archived (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Forcing current WAL file to be archived
|
Список | pgsql-hackers |
On Tue, 2006-07-25 at 11:07 -0400, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > Where are we on these TODO items: > > > o Allow point-in-time recovery to archive partially filled > > write-ahead logs [pitr] > > I believe we'd agreed that the necessary infrastructure for this is > just a function to tell the current WAL segment name and offset. Not that I remember. That was just a proposal for backpatching to 8.1/8.0 so that it would be easier to cope with PITR at those releases. > > o Automatically force archiving of partially-filled WAL files when > > pg_stop_backup() is called or the server is stopped > > I see no need for that to be "automatic". I'd vote for a simple > function pg_finish_wal_segment() or something like that, which you > call just after pg_stop_backup() if you want this behavior. Trying > to tie it into pg_stop_backup() will only make things more complicated > and less flexible. Putting it into pg_stop_backup was what we previously agreed. Where is the loss of flexibility? I need to get this straight because I was actually intending to do this for 8.2, i.e. next few days. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: