Thread: ALTER SYSTEM between upgrades
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
> On 14 Jul 2020, at 01:58, Bruce Momjian <bruce@momjian.us> wrote: > 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. Transferring postgresql.conf is discussed to some degree in the documentation for pg_upgrade: 11. Restore pg_hba.conf If you modified pg_hba.conf, restore its original settings. It might also be necessary to adjust other configuration files in the new cluster to match the old cluster, e.g. postgresql.conf. .. as well as upgrading via pg_dumpall: 4. Restore your previous pg_hba.conf and any postgresql.conf modifications. One can argue whether those bulletpoints are sufficient for stressing the importance, but it's at least mentioned. There is however no mention of postgresql.auto.conf which clearly isn't helping anyone, so we should fix that. Taking that a step further, maybe we should mention additional config files which could be included via include directives? There are tools out there who avoid changing the users postgresql.conf by injecting an include directive instead; they might've placed the included file alongside postgresql.conf. cheers ./daniel
On Tue, Jul 14, 2020 at 12:52:23PM +0200, Daniel Gustafsson wrote: > > On 14 Jul 2020, at 01:58, Bruce Momjian <bruce@momjian.us> wrote: > > > 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. > > Transferring postgresql.conf is discussed to some degree in the documentation > for pg_upgrade: > > 11. Restore pg_hba.conf > If you modified pg_hba.conf, restore its original settings. It might > also be necessary to adjust other configuration files in the new > cluster to match the old cluster, e.g. postgresql.conf. > > .. as well as upgrading via pg_dumpall: > > 4. Restore your previous pg_hba.conf and any postgresql.conf > modifications. > > One can argue whether those bulletpoints are sufficient for stressing the > importance, but it's at least mentioned. There is however no mention of > postgresql.auto.conf which clearly isn't helping anyone, so we should fix that. > > Taking that a step further, maybe we should mention additional config files > which could be included via include directives? There are tools out there who > avoid changing the users postgresql.conf by injecting an include directive > instead; they might've placed the included file alongside postgresql.conf. I have developed the attached pg_upgrade doc patch to address this. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
Attachment
> On 25 Aug 2020, at 21:30, Bruce Momjian <bruce@momjian.us> wrote: > > On Tue, Jul 14, 2020 at 12:52:23PM +0200, Daniel Gustafsson wrote: >>>> On 14 Jul 2020, at 01:58, Bruce Momjian <bruce@momjian.us> wrote: >>> >>> 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. >> >> Transferring postgresql.conf is discussed to some degree in the documentation >> for pg_upgrade: >> >> 11. Restore pg_hba.conf >> If you modified pg_hba.conf, restore its original settings. It might >> also be necessary to adjust other configuration files in the new >> cluster to match the old cluster, e.g. postgresql.conf. >> >> .. as well as upgrading via pg_dumpall: >> >> 4. Restore your previous pg_hba.conf and any postgresql.conf >> modifications. >> >> One can argue whether those bulletpoints are sufficient for stressing the >> importance, but it's at least mentioned. There is however no mention of >> postgresql.auto.conf which clearly isn't helping anyone, so we should fix that. >> >> Taking that a step further, maybe we should mention additional config files >> which could be included via include directives? There are tools out there who >> avoid changing the users postgresql.conf by injecting an include directive >> instead; they might've placed the included file alongside postgresql.conf. > > I have developed the attached pg_upgrade doc patch to address this. LGTM, thanks! cheers ./daniel
On Wed, Aug 26, 2020 at 12:22:25AM +0200, Daniel Gustafsson wrote: > >> One can argue whether those bulletpoints are sufficient for stressing the > >> importance, but it's at least mentioned. There is however no mention of > >> postgresql.auto.conf which clearly isn't helping anyone, so we should fix that. > >> > >> Taking that a step further, maybe we should mention additional config files > >> which could be included via include directives? There are tools out there who > >> avoid changing the users postgresql.conf by injecting an include directive > >> instead; they might've placed the included file alongside postgresql.conf. > > > > I have developed the attached pg_upgrade doc patch to address this. > > LGTM, thanks! Patch applied, -- Bruce Momjian <bruce@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee