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: Sun, 4 Jul 2021 22:38:33 +1200
Message-ID: <CAApHDvqu_6JetmiPUuM-_f=r7GHXiaxLXJu8JFe-vjMPHW73eg@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CABeG9LsZ2ozUMcqtqWu_-GiFKB17ih3p8wBHXcpfnHqhCnsc7A@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<CAApHDvrSDxi2jvStdi4vnrD3JjMffSkEZhK8C3-NsLV+CFhL8A@mail.gmail.com>
	<[email protected]>

On Sat, 3 Jul 2021 at 00:40, Laurenz Albe <[email protected]> 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


Attachments:

  [application/octet-stream] set_maxvalue_for_autovacuum_work_mem_to_1gb.patch (466B, 2-set_maxvalue_for_autovacuum_work_mem_to_1gb.patch)
  download | inline diff:
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: <CAApHDvqu_6JetmiPUuM-_f=r7GHXiaxLXJu8JFe-vjMPHW73eg@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