v.popoli...@postgrespro.ru писал(а) 2024-10-01 00:30:
David Rowley писал(а) 2024-09-24 01:07:
On Tue, 24 Sept 2024 at 02:47, Vladlen Popolitov
<v.popoli...@postgrespro.ru> wrote:
I agree, it is better to fix all them together. I also do not like
this
hack, it will be removed from the patch, if I check and change
all <work_mem_vars> at once.
I think, it will take about 1 week to fix and test all changes. I
will
estimate the total volume of the changes and think, how to group them
in the patch ( I hope, it will be only one patch)
There's a few places that do this:
Size maxBlockSize = ALLOCSET_DEFAULT_MAXSIZE;
/* choose the maxBlockSize to be no larger than 1/16 of work_mem */
while (16 * maxBlockSize > work_mem * 1024L)
I think since maxBlockSize is a Size variable, that the above should
probably be:
while (16 * maxBlockSize > (Size) work_mem * 1024)
Maybe there can be a precursor patch to fix all those to get rid of
the 'L' and cast to the type we're comparing to or assigning to rather
than trying to keep the result of the multiplication as a long.
Hi
I rechecked all <work_mem_vars>, that depend on MAX_KILOBYTES limit and
fixed
all casts that are affected by 4-bytes long type in Windows 64-bit. Now
next variables are limited by 2TB in all 64-bit systems:
maintenance_work_mem
work_mem
logical_decoding_work_mem
max_stack_depth
autovacuum_work_mem
gin_pending_list_limit
wal_skip_threshold
Also wal_keep_size_mb, min_wal_size_mb, max_wal_size_mb,
max_slot_wal_keep_size_mb are not affected by "long" cast.
Hi everyone.
The patch added to Commitfest:
https://commitfest.postgresql.org/50/5343/
--
Best regards,
Vladlen Popolitov.
