Daniel, Jeff,
> I don't doubt this, that's why I do have a no-op fallback for
> emergencies. The discussion was about defaults. I still think that
> drop-wal-from-archiving-whenever is not a good one.
Yeah, we can argue defaults for a long time. What would be better is
some way to actually determine what the user is trying to do, or wants
to happen. That's why I'd be in favor of an explict setting; if there's
a setting which says:
on_archive_failure=shutdown
... then it's a LOT clearer to the user what will happen if the archive
runs out of space, even if we make no change to the defaults. And if
that setting is changeable on reload, it even becomes a way for users to
get out of tight spots.
> You may have noticed I also wrote that a neater, common way to drop
> WAL when under pressure might be nice, to avoid having it ad-hoc and
> all over, so it's not as though I wanted to suggest an Postgres
> feature to this effect was an anti-feature.
Yep. Drake was saying it was an anti-feature, though, so I was arguing
with him.
> Well it seems to me that one of the problems here is we tell people to use
>> copy. We should be telling people to use a command (or supply a command)
>> that is smarter than that.
>>
>
> Actually we describe what archive_command needs to fulfill, and tell them
> to use something that accomplishes that. The example with cp is explicitly
> given as an example, not a recommendation.
If we offer cp as an example, we *are* recommending it. If we don't
recommend it, we shouldn't have it as an example.
In fact, if we don't recommend cp, then PostgreSQL should ship with some
example shell scripts for archive commands, just as we do for init scripts.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
