From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Amit Kapila <amit.kapila16@gmail.com>
Cc: Jeff Davis <pgsql@j-davis.com>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Justin Pryzby <pryzby@telsasoft.com>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: David Rowley <dgrowleyml@gmail.com>
Cc: Melanie Plageman <melanieplageman@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Default setting for enable_hashagg_disk (hash_mem)
Date: Tue, 7 Jul 2020 16:53:00 -0400
Message-ID: <20200707205300.GA26641@alvherre.pgsql> (raw)
In-Reply-To: <CAH2-WznkV2QRm1Jh3pceEnK9v2UyceacYw4ywY9fUA-8VU5m+A@mail.gmail.com>
On 2020-Jul-07, Peter Geoghegan wrote:
> On Tue, Jul 7, 2020 at 1:18 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> > Yeah, backporting GUCs is not a big deal. Sure, the GUC won't appear in
> > postgresql.conf files generated by initdb prior to the release that
> > introduces it. But users that need it can just edit their .confs and
> > add the appropriate line, or just do ALTER SYSTEM after the minor
> > upgrade.
>
> I don't buy that argument myself. At a minimum, if we do it then we
> ought to feel bad about it. It should be rare.
Judging history, it's pretty clear that it *is* rare. I'm not
suggesting we do it now. I'm just contesting the assertion that it's
impossible.
> The fact that you can have a replica on an earlier point release
> enforces the idea that it ought to be broadly compatible.
A replica without hash_mem is not going to fail if the primary is
upgraded to a version with hash_mem, so I'm not sure this argument
means anything in this case. In any case, when we add WAL message types
in minor releases, users are suggested to upgrade the replicas first; if
they fail to do so, the replicas shut down when they reach a WAL point
where the primary emitted the new message. Generally speaking, we *don't*
promise that running a replica with an older minor always works, though
obviously it does work most of the time.
> Technically
> users are not guaranteed that this will work, just like there are no
> guarantees about WAL compatibility across point releases. We
> nevertheless tacitly provide a "soft" guarantee that we won't break
> WAL -- and that we won't add entirely new GUCs in a point release.
Agreed, we do provide those guarantees.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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: alvherre@2ndquadrant.com, pg@bowt.ie, amit.kapila16@gmail.com, pgsql@j-davis.com, bruce@momjian.us, pryzby@telsasoft.com, tomas.vondra@2ndquadrant.com, robertmhaas@gmail.com, andres@anarazel.de, dgrowleyml@gmail.com, melanieplageman@gmail.com
Subject: Re: Default setting for enable_hashagg_disk (hash_mem)
In-Reply-To: <20200707205300.GA26641@alvherre.pgsql>
* 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