From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Forcing current WAL file to be archived |
Date: | 2006-07-25 15:58:51 |
Message-ID: | 20060725155851.GM20016@kenobi.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Simon Riggs (simon(at)2ndquadrant(dot)com) wrote:
> On Tue, 2006-07-25 at 11:20 -0400, Bruce Momjian wrote:
> > Yes, perhaps, though I can envision a GUC that does regularly partial
> > archiving. I will add a question mark to the item.
>
> I was planning to add a new GUC
>
> archive_timeout (integer) = max # secs between log file switches
I'd love to see both this GUC and the function itself make it into 8.2..
I'm tempted to agree with Bruce about running the wal-archive-function
after pg_stop_backup(). The backup isn't any good without all the WALs
which were used during the backup anyway (iirc) so I can't really think
why you'd want any time at all between "backup happening" and "backup
actually usable".
Also, compared to the backup itself I'd tend to doubt there would be
much of a performance hit. It may be expensive compared to other
regular queries/operations but an rsync across the entire database isn't
exactly cheap.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2006-07-25 16:00:47 | Re: Forcing current WAL file to be archived |
Previous Message | Bruce Momjian | 2006-07-25 15:57:30 | Re: Forcing current WAL file to be archived |