On Mon, Sep 19, 2022 at 12:49:58PM -0400, Robert Haas wrote: > On Mon, Sep 19, 2022 at 10:39 AM Noah Misch <n...@leadboat.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.
