Re: Default setting for enable_hashagg_disk (hash_mem) - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Default setting for enable_hashagg_disk (hash_mem)
Date
Msg-id CAH2-WznkV2QRm1Jh3pceEnK9v2UyceacYw4ywY9fUA-8VU5m+A@mail.gmail.com
Whole thread Raw
In response to Re: Default setting for enable_hashagg_disk (hash_mem)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: Default setting for enable_hashagg_disk (hash_mem)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
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.

The fact that you can have a replica on an earlier point release
enforces the idea that it ought to be broadly compatible. 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.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Default setting for enable_hashagg_disk (hash_mem)
Next
From: Daniel Gustafsson
Date:
Subject: Re: OpenSSL 3.0.0 compatibility