Since the introduction of TID store, vacuum uses far less memory in
the common case than in versions 16 and earlier. Invoking multiple
rounds of index vacuuming in turn requires a much larger table. It'd
be a good idea anyway to cover this case in regression testing, and a
lower limit is less painful for slow buildfarm animals. The reason to
do it now is to re-enable coverage of the bugfix in commit
83c39a1f7f.
For consistency, give autovacuum_work_mem the same treatment.
Suggested by Andres Freund
Tested by Melanie Plageman
Backpatch to v17, where TID store was introduced
Discussion: https://postgr.es/m/
20240516205458.ohvlzis5b5tvejru@awork3.anarazel.de
Discussion: https://postgr.es/m/
20240722164745.fvaoh6g6zprisqgp%40awork3.anarazel.de
return true;
/*
- * We clamp manually-set values to at least 1MB. Since
+ * We clamp manually-set values to at least 64kB. Since
* maintenance_work_mem is always set to at least this value, do the same
* here.
*/
- if (*newval < 1024)
- *newval = 1024;
+ if (*newval < 64)
+ *newval = 64;
return true;
}
NULL, NULL, NULL
},
+ /*
+ * Dynamic shared memory has a higher overhead than local memory contexts,
+ * so when testing low-memory scenarios that could use shared memory, the
+ * recommended minimum is 1MB.
+ */
{
{"maintenance_work_mem", PGC_USERSET, RESOURCES_MEM,
gettext_noop("Sets the maximum memory to be used for maintenance operations."),
GUC_UNIT_KB
},
&maintenance_work_mem,
- 65536, 1024, MAX_KILOBYTES,
+ 65536, 64, MAX_KILOBYTES,
NULL, NULL, NULL
},
# you actively intend to use prepared transactions.
#work_mem = 4MB # min 64kB
#hash_mem_multiplier = 2.0 # 1-1000.0 multiplier on hash table work_mem
-#maintenance_work_mem = 64MB # min 1MB
-#autovacuum_work_mem = -1 # min 1MB, or -1 to use maintenance_work_mem
+#maintenance_work_mem = 64MB # min 64kB
+#autovacuum_work_mem = -1 # min 64kB, or -1 to use maintenance_work_mem
#logical_decoding_work_mem = 64MB # min 64kB
#max_stack_depth = 2MB # min 100kB
#shared_memory_type = mmap # the default is the first option