From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | Martín Marqués <martin(dot)marques(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Update maintenance_work_mem/autovacuum_work_mem to reflect the 1GB limitation with VACUUM |
Date: | 2021-07-04 10:38:33 |
Message-ID: | CAApHDvqu_6JetmiPUuM-_f=r7GHXiaxLXJu8JFe-vjMPHW73eg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs pgsql-hackers |
On Sat, 3 Jul 2021 at 00:40, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)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
Attachment | Content-Type | Size |
---|---|---|
set_maxvalue_for_autovacuum_work_mem_to_1gb.patch | application/octet-stream | 466 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | PG Doc comments form | 2021-07-04 20:37:08 | Second-granular timezone offset format not documented |
Previous Message | PG Doc comments form | 2021-07-03 11:54:11 | ECPG cursor examples should include EXEC SQL WHENEVER NOT FOUND CONTINUE; after the while loop |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2021-07-04 10:49:13 | Re: Reducing the cycle time for CLOBBER_CACHE_ALWAYS buildfarm members |
Previous Message | Fabien COELHO | 2021-07-04 09:35:09 | Re: rand48 replacement |