On 06/06/2013 09:30 PM, Jeff Janes wrote:
Archiving
---------
In some ways, this is the simplest case. Really, we just need a way to
know when the available WAL space has become 90% full, and abort
archiving at that stage. Once we stop attempting to archive, we can
clean up the unneeded log segments.
I would oppose that as the solution, either an unconditional one, or
configurable with is it as the default. Those segments are not
unneeded. I need them. That is why I set up archiving in the first
place. If you need to shut down the database rather than violate my
established retention policy, then shut down the database.
Agreed and I would oppose it even as configurable. We set up the
archiving for a reason. I do think it might be useful to be able to
store archiving logs as well as wal_keep_segments logs in a different
location than pg_xlog.
What we need is a better way for the DBA to find out that archiving is
falling behind when it first starts to fall behind. Tailing the log and
examining the rather cryptic error messages we give out isn't very
effective.
The archive command can be made a shell script (or that matter a
compiled program) which can do anything it wants upon failure, including
emailing people.
Yep, that is what PITRTools does. You can make it do whatever you want.
JD
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
