>> 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.
People have different configurations. Most of my clients use archiving
for backup or replication; they would rather have archiving cease (and
send a CRITICAL alert) than have the master go offline. That's pretty
common, probably more common than the "if I don't have redundancy shut
down" case.
Certainly anyone making the decision that their master database should
shut down rather than cease archiving should make it *consciously*,
instead of finding out the hard way.
>> 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.
You're talking about using external tools -- frequently hackish,
workaround ones -- to handle something which PostgreSQL should be doing
itself, and which only the database engine has full knowledge of. While
that's the only solution we have for now, it's hardly a worthy design goal.
Right now, what we're telling users is "You can have continuous backup
with Postgres, but you'd better hire and expensive consultant to set it
up for you, or use this external tool of dubious provenance which
there's no packages for, or you might accidentally cause your database
to shut down in the middle of the night."
At which point most sensible users say "no thanks, I'll use something else".
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com