Re: remove more archiving overhead

On Mon, Sep 19, 2022 at 12:49:58PM -0400, Robert Haas wrote:
> On Mon, Sep 19, 2022 at 10:39 AM Noah Misch <noah(at)leadboat(dot)com> wrote:
> > I wanted it to stop saying anything like the second paragraph, hence commit
> > d263ced. Implementing a proper archiving setup is not especially difficult,
> > and inviting the operator to work around a wrong implementation invites
> > damaging mistakes under time pressure.
>
> I agree wholeheartedly with the second sentence. I do think that we
> need to be a little careful not to be too prescriptive. Telling people
> what they have to do when they don't really have to do it often leads
> to non-compliance. It can be more productive to spell out the precise
> consequences of non-compliance, so I think Peter's proposal has some
> merit.

Good point. We could say it from a perspective like, "if you don't do this,
your setup will appear to work most of the time, but your operator will be
stuck with dangerous manual fixes at times."

> On the other hand, I don't see any real problem with the
> current language, either.
>
> Unfortunately, no matter what we do here, it is not likely that we'll
> soon be able to eliminate the phenomenon where people use a buggy
> home-grown archive_command, both because we've been encouraging that
> in our documentation for a very long time, and also because the people
> who are most likely to do something half-baked here are probably the
> least likely to actually read the updated documentation.

True. If I wanted to eliminate such setups, I would make the server
double-archive one WAL file each time the archive setup changes.