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
