Date: Mon, 19 Sep 2022 21:52:18 -0700
From: Noah Misch <noah@leadboat.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
	Nathan Bossart <nathandbossart@gmail.com>,
	David Steele <david@pgmasters.net>,
	Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
	Fujii Masao <masao.fujii@oss.nttdata.com>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: remove more archiving overhead
Message-ID: <20220920045218.GA1724802@rfd.leadboat.com>
References: <20220708165450.GA2356733@nathanxps13>
 <20220731065156.GA3694276@rfd.leadboat.com>
 <20220802050219.GA475090@nathanxps13>
 <20220803071617.GA3817792@rfd.leadboat.com>
 <ebb0f19f-5452-678c-0d19-1b8b260fd331@enterprisedb.com>
 <20220917215427.GB3189289@nathanxps13>
 <20220918071312.GB1658466@rfd.leadboat.com>
 <7476bc05-3b8d-dab4-64e9-b569c54631d6@enterprisedb.com>
 <20220919143923.GA1706070@rfd.leadboat.com>
 <CA+TgmoZ5=rndPZHKQiXk3x6Fi16+Sob6kU=8Lh8nJnMrrkpvfg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CA+TgmoZ5=rndPZHKQiXk3x6Fi16+Sob6kU=8Lh8nJnMrrkpvfg@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: 
 <https://www.postgresql.org/message-id/20220920045218.GA1724802%40rfd.leadboat.com>
Precedence: bulk

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@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.