public inbox for [email protected]  

help / color / mirror / Atom feed

From: David Rowley <[email protected]>
To: Laurenz Albe <[email protected]>
Cc: Martín Marqués <[email protected]>
Cc: PostgreSQL Developers <[email protected]>
Subject: Re: Update maintenance_work_mem/autovacuum_work_mem to reflect the 1GB limitation with VACUUM
Date: Fri, 2 Jul 2021 23:31:07 +1200
Message-ID: <CAApHDvrSDxi2jvStdi4vnrD3JjMffSkEZhK8C3-NsLV+CFhL8A@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CABeG9LsZ2ozUMcqtqWu_-GiFKB17ih3p8wBHXcpfnHqhCnsc7A@mail.gmail.com>
	<[email protected]>
	<[email protected]>

On Fri, 21 May 2021 at 03:52, Laurenz Albe <[email protected]> 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


Attachments:

  [application/octet-stream] limit_vacuum_memory_to_1gb.patch (1.1K, 2-limit_vacuum_memory_to_1gb.patch)
  download | inline diff:
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 6098f6b020..a7281c8e73 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -1893,6 +1893,11 @@ include_dir 'conf.d'
         too high.  It may be useful to control for this by separately
         setting <xref linkend="guc-autovacuum-work-mem"/>.
        </para>
+       <para>
+        Additionally, <command>VACUUM</command> is only able to utilize up to
+        a maximum of 1GB of memory, so <varname>maintenance_work_mem</varname>
+        values higher than this have no effect on <command>VACUUM</command>.
+       </para>
       </listitem>
      </varlistentry>
 
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index 480e8cd199..bb76baa72d 100644
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -3340,7 +3340,8 @@ static struct config_int ConfigureNamesInt[] =
 			GUC_UNIT_KB
 		},
 		&autovacuum_work_mem,
-		-1, -1, MAX_KILOBYTES,
+		/* see compute_max_dead_tuples if you need to change the max value */
+		-1, -1, 1024 * 1024,
 		check_autovacuum_work_mem, NULL, NULL
 	},
 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Update maintenance_work_mem/autovacuum_work_mem to reflect the 1GB limitation with VACUUM
  In-Reply-To: <CAApHDvrSDxi2jvStdi4vnrD3JjMffSkEZhK8C3-NsLV+CFhL8A@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox