From: Noah Misch <noah@leadboat.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>
Cc: David Steele <david@pgmasters.net>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: remove more archiving overhead
Date: Mon, 19 Sep 2022 21:52:18 -0700
Message-ID: <20220920045218.GA1724802@rfd.leadboat.com> (raw)
In-Reply-To: <CA+TgmoZ5=rndPZHKQiXk3x6Fi16+Sob6kU=8Lh8nJnMrrkpvfg@mail.gmail.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>
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.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: noah@leadboat.com, robertmhaas@gmail.com, peter.eisentraut@enterprisedb.com, nathandbossart@gmail.com, david@pgmasters.net, horikyota.ntt@gmail.com, masao.fujii@oss.nttdata.com
Subject: Re: remove more archiving overhead
In-Reply-To: <20220920045218.GA1724802@rfd.leadboat.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox