Обсуждение: 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
Вложения
> 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