ALTER SYSTEM between upgrades

Bruce Momjian <bruce@momjian.us>

From: Bruce Momjian <bruce@momjian.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: PostgreSQL-documentation <pgsql-docs@postgresql.org>
Date: 2020-07-13T23:58:49Z
Lists: pgsql-hackers, pgsql-docs
On Tue, Jul  7, 2020 at 04:18:21PM -0400, Alvaro Herrera wrote:
> On 2020-Jul-07, Amit Kapila wrote:
> 
> > I don't think this is true.  We seem to have introduced three new guc
> > variables in a 9.3.3 minor release.
> 
> 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.  For people that don't need it, it would have a reasonable
> default (probably work_mem, so that behavior doesn't change on the minor
> upgrade).

I am creating a new thread to discuss the question raised by Alvaro of
how many ALTER SYSTEM settings are lost during major upgrades.  Do we
properly document that users should migrate their postgresql.conf _and_
postgresql.auto.conf files during major upgrades?  I personally never
thought of this until now.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee




Commits

  1. Add hash_mem_multiplier GUC.

  2. HashAgg: use better cardinality estimate for recursive spilling.

  3. Remove hashagg_avoid_disk_plan GUC.

  4. Doc fixup for hashagg_avoid_disk_plan GUC.

  5. Rework HashAgg GUCs.

  6. Disk-based Hash Aggregation.

  7. Implement partition-wise grouping/aggregation.

  8. Defer creation of partially-grouped relation until it's needed.