MIME-Version: 1.0
References: 
 <CABeG9LsZ2ozUMcqtqWu_-GiFKB17ih3p8wBHXcpfnHqhCnsc7A@mail.gmail.com>
 <1c6fa18692a77ff6098dedc0c150df24ffe9db89.camel@cybertec.at>
 <f311f6eda1bd8a6c319a969881b0c15e6fbbfaa8.camel@cybertec.at>
 <CAApHDvrSDxi2jvStdi4vnrD3JjMffSkEZhK8C3-NsLV+CFhL8A@mail.gmail.com>
 <db6f5ddc36bf358affaa83a57487ab6ce77d5bcc.camel@cybertec.at>
In-Reply-To: <db6f5ddc36bf358affaa83a57487ab6ce77d5bcc.camel@cybertec.at>
From: David Rowley <dgrowleyml@gmail.com>
Date: Sun, 4 Jul 2021 22:38:33 +1200
Message-ID: 
 <CAApHDvqu_6JetmiPUuM-_f=r7GHXiaxLXJu8JFe-vjMPHW73eg@mail.gmail.com>
Subject: Re: Update maintenance_work_mem/autovacuum_work_mem to reflect the
 1GB limitation with VACUUM
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: =?UTF-8?B?TWFydMOtbiBNYXJxdcOpcw==?= <martin.marques@gmail.com>,
	PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Content-Type: multipart/mixed; boundary="000000000000d3789f05c649cb66"
Archived-At: 
 <https://www.postgresql.org/message-id/CAApHDvqu_6JetmiPUuM-_f%3Dr7GHXiaxLXJu8JFe-vjMPHW73eg%40mail.gmail.com>
Precedence: bulk

--000000000000d3789f05c649cb66
Content-Type: text/plain; charset="UTF-8"

On Sat, 3 Jul 2021 at 00:40, Laurenz Albe <laurenz.albe@cybertec.at> wrote:
>
> On Fri, 2021-07-02 at 23:31 +1200, David Rowley wrote:
> > I had a look at the patch in [1] and I find it a bit weird that we'd
> > write the following about autovacuum_work_mem in our docs:
> >
> > +       <para>
> > +        Note that <command>VACUUM</command> has a hard-coded limit of 1GB
> > +        for the amount of memory used, so setting
> > +        <varname>autovacuum_work_mem</varname> higher than that has no effect.
> > +       </para>
> >
> > Since that setting is *only* used for auto vacuum, why don't we just
> > limit the range of the GUC to 1GB?
> >
> > Of course, it wouldn't be wise to backpatch the reduced limit of
> > autovacuum_work_mem as it might upset people who have higher values in
> > their postgresql.conf when their database fails to restart after an
> > upgrade. I think what might be best is just to reduce the limit in
> > master and apply the doc patch for just maintenance_work_mem in all
> > supported versions. We could just ignore doing anything with
> > autovacuum_work_mem in the back branches and put it down to a
> > historical mistake that can't easily be fixed now.
> >
>
> I think that is much better.
> I am fine with that patch.

Thanks for looking.  I've pushed the doc fix patch for
maintenance_work_mem and back-patched to 9.6.

I could do with a 2nd opinion about if we should just adjust the
maximum value for the autovacuum_work_mem GUC to 1GB in master.

I'm also not sure if since we'd not backpatch the GUC max value
adjustment if we need to document the upper limit in the manual.

David

--000000000000d3789f05c649cb66
Content-Type: application/octet-stream;
	name="set_maxvalue_for_autovacuum_work_mem_to_1gb.patch"
Content-Disposition: attachment;
	filename="set_maxvalue_for_autovacuum_work_mem_to_1gb.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_kqp29v220>
X-Attachment-Id: f_kqp29v220

ZGlmZiAtLWdpdCBhL3NyYy9iYWNrZW5kL3V0aWxzL21pc2MvZ3VjLmMgYi9zcmMvYmFja2VuZC91
dGlscy9taXNjL2d1Yy5jCmluZGV4IDQ4MGU4Y2QxOTkuLmJiNzZiYWE3MmQgMTAwNjQ0Ci0tLSBh
L3NyYy9iYWNrZW5kL3V0aWxzL21pc2MvZ3VjLmMKKysrIGIvc3JjL2JhY2tlbmQvdXRpbHMvbWlz
Yy9ndWMuYwpAQCAtMzM0MCw3ICszMzQwLDggQEAgc3RhdGljIHN0cnVjdCBjb25maWdfaW50IENv
bmZpZ3VyZU5hbWVzSW50W10gPQogCQkJR1VDX1VOSVRfS0IKIAkJfSwKIAkJJmF1dG92YWN1dW1f
d29ya19tZW0sCi0JCS0xLCAtMSwgTUFYX0tJTE9CWVRFUywKKwkJLyogc2VlIGNvbXB1dGVfbWF4
X2RlYWRfdHVwbGVzIGlmIHlvdSBuZWVkIHRvIGNoYW5nZSB0aGUgbWF4IHZhbHVlICovCisJCS0x
LCAtMSwgMTAyNCAqIDEwMjQsCiAJCWNoZWNrX2F1dG92YWN1dW1fd29ya19tZW0sIE5VTEwsIE5V
TEwKIAl9LAogCg==
--000000000000d3789f05c649cb66--