MIME-Version: 1.0
References: 
 <CABeG9LsZ2ozUMcqtqWu_-GiFKB17ih3p8wBHXcpfnHqhCnsc7A@mail.gmail.com>
 <1c6fa18692a77ff6098dedc0c150df24ffe9db89.camel@cybertec.at>
 <f311f6eda1bd8a6c319a969881b0c15e6fbbfaa8.camel@cybertec.at>
In-Reply-To: <f311f6eda1bd8a6c319a969881b0c15e6fbbfaa8.camel@cybertec.at>
From: David Rowley <dgrowleyml@gmail.com>
Date: Fri, 2 Jul 2021 23:31:07 +1200
Message-ID: 
 <CAApHDvrSDxi2jvStdi4vnrD3JjMffSkEZhK8C3-NsLV+CFhL8A@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="0000000000001943af05c6224cf1"
Archived-At: 
 <https://www.postgresql.org/message-id/CAApHDvrSDxi2jvStdi4vnrD3JjMffSkEZhK8C3-NsLV%2BCFhL8A%40mail.gmail.com>
Precedence: bulk

--0000000000001943af05c6224cf1
Content-Type: text/plain; charset="UTF-8"

On Fri, 21 May 2021 at 03:52, Laurenz Albe <laurenz.albe@cybertec.at> wrote:
> Just sending a reply to -hackers so I can add it to the commitfest.

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've attached what I came up with.

What do you think?

[1] https://www.postgresql.org/message-id/514fe5ce4714b7b33cb0a611f0c7b72df413bef5.camel%40cybertec.at

--0000000000001943af05c6224cf1
Content-Type: application/octet-stream;
	name="limit_vacuum_memory_to_1gb.patch"
Content-Disposition: attachment; filename="limit_vacuum_memory_to_1gb.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_kqm96q2r0>
X-Attachment-Id: f_kqm96q2r0

ZGlmZiAtLWdpdCBhL2RvYy9zcmMvc2dtbC9jb25maWcuc2dtbCBiL2RvYy9zcmMvc2dtbC9jb25m
aWcuc2dtbAppbmRleCA2MDk4ZjZiMDIwLi5hNzI4MWM4ZTczIDEwMDY0NAotLS0gYS9kb2Mvc3Jj
L3NnbWwvY29uZmlnLnNnbWwKKysrIGIvZG9jL3NyYy9zZ21sL2NvbmZpZy5zZ21sCkBAIC0xODkz
LDYgKzE4OTMsMTEgQEAgaW5jbHVkZV9kaXIgJ2NvbmYuZCcKICAgICAgICAgdG9vIGhpZ2guICBJ
dCBtYXkgYmUgdXNlZnVsIHRvIGNvbnRyb2wgZm9yIHRoaXMgYnkgc2VwYXJhdGVseQogICAgICAg
ICBzZXR0aW5nIDx4cmVmIGxpbmtlbmQ9Imd1Yy1hdXRvdmFjdXVtLXdvcmstbWVtIi8+LgogICAg
ICAgIDwvcGFyYT4KKyAgICAgICA8cGFyYT4KKyAgICAgICAgQWRkaXRpb25hbGx5LCA8Y29tbWFu
ZD5WQUNVVU08L2NvbW1hbmQ+IGlzIG9ubHkgYWJsZSB0byB1dGlsaXplIHVwIHRvCisgICAgICAg
IGEgbWF4aW11bSBvZiAxR0Igb2YgbWVtb3J5LCBzbyA8dmFybmFtZT5tYWludGVuYW5jZV93b3Jr
X21lbTwvdmFybmFtZT4KKyAgICAgICAgdmFsdWVzIGhpZ2hlciB0aGFuIHRoaXMgaGF2ZSBubyBl
ZmZlY3Qgb24gPGNvbW1hbmQ+VkFDVVVNPC9jb21tYW5kPi4KKyAgICAgICA8L3BhcmE+CiAgICAg
ICA8L2xpc3RpdGVtPgogICAgICA8L3Zhcmxpc3RlbnRyeT4KIApkaWZmIC0tZ2l0IGEvc3JjL2Jh
Y2tlbmQvdXRpbHMvbWlzYy9ndWMuYyBiL3NyYy9iYWNrZW5kL3V0aWxzL21pc2MvZ3VjLmMKaW5k
ZXggNDgwZThjZDE5OS4uYmI3NmJhYTcyZCAxMDA2NDQKLS0tIGEvc3JjL2JhY2tlbmQvdXRpbHMv
bWlzYy9ndWMuYworKysgYi9zcmMvYmFja2VuZC91dGlscy9taXNjL2d1Yy5jCkBAIC0zMzQwLDcg
KzMzNDAsOCBAQCBzdGF0aWMgc3RydWN0IGNvbmZpZ19pbnQgQ29uZmlndXJlTmFtZXNJbnRbXSA9
CiAJCQlHVUNfVU5JVF9LQgogCQl9LAogCQkmYXV0b3ZhY3V1bV93b3JrX21lbSwKLQkJLTEsIC0x
LCBNQVhfS0lMT0JZVEVTLAorCQkvKiBzZWUgY29tcHV0ZV9tYXhfZGVhZF90dXBsZXMgaWYgeW91
IG5lZWQgdG8gY2hhbmdlIHRoZSBtYXggdmFsdWUgKi8KKwkJLTEsIC0xLCAxMDI0ICogMTAyNCwK
IAkJY2hlY2tfYXV0b3ZhY3V1bV93b3JrX21lbSwgTlVMTCwgTlVMTAogCX0sCiAK
--0000000000001943af05c6224cf1--