Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> 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 available for 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 [EMAIL PROTECTED] EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match