Re: Hard limit on WAL space used (because PANIC sucks)

On Wed, Jun 12, 2013 at 6:03 PM, Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:
>
>> Right now you have to be a rocket
>> scientist no matter what configuration you're running.
>
>
> This is quite a bit overblown. Assuming your needs are simple. Archiving is
> at it is now, a relatively simple process to set up, even without something
> like PITRTools. Where we run into trouble is when they aren't and that is
> ok because we can't solve every problem. We can only provide tools for
> others to solve their particular issue.
>
> What concerns me is we seem to be trying to make this "easy". It isn't
> supposed to be easy. This is hard stuff. Smart people built it and it takes
> a smart person to run it. When did it become a bad thing to be something
> that smart people need to run?
>
> Yes, we need to make it reliable. We don't need to be the Nanny database.

More than easy, it should be obvious.

Obvious doesn't mean easy, it just means what you have to do to get it
right is clearly in front of you. When you give people the freedom of
an "archive command", you also take away any guidance more restricting
options give. I think the point here is that a default would guide
people in how to make this work reliably, without having to rediscover
it every time. A good, *obvious* (not easy) default. Even "cp blah to
NFS mount" is obvious, while not easy (setting up an NFS through
firewalls is never easy).

So, having archive utilities in place of cp would ease the burden of
administration, because it'd be based on collective knowledge. Some
"pg_cp" (or more likely "pg_archive_wal") could check there's enough
space, and whatever else collective knowledge decided is necessary.