Re: Forcing current WAL file to be archived
От | Bruce Momjian |
---|---|
Тема | Re: Forcing current WAL file to be archived |
Дата | |
Msg-id | 200607251520.k6PFKeN10814@momjian.us обсуждение исходный текст |
Ответ на | Re: Forcing current WAL file to be archived (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Forcing current WAL file to be archived
Re: Forcing current WAL file to be archived |
Список | pgsql-hackers |
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. Yes, perhaps, though I can envision a GUC that does regularly partial archiving. I will add a question mark to the item. In fact, the description has more details: o Allow point-in-time recovery to archive partially filled write-ahead logs? [pitr] Currently only full WAL files are archived. This means that the most recent transactions aren't availablefor recovery in case of a disk failure. This could be triggered by a user command or a timer. > > 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. I assumed we would have a function like pg_finish_wal_segment(), and server stop and stop_backup would call it too, the reason being, it would greatly simplify our documentation on how to use PITR if these were done automatically. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-hackers по дате отправления: