Re: Increase of maintenance_work_mem limit in 64-bit Windows

Vladlen Popolitov <v.popolitov@postgrespro.ru>

From: v.popolitov@postgrespro.ru
To: David Rowley <dgrowleyml@gmail.com>
Cc: pgsql-hackers@postgresql.org
Date: 2024-09-30T21:30:40Z
Lists: pgsql-hackers

Attachments

David Rowley писал(а) 2024-09-24 01:07:
> On Tue, 24 Sept 2024 at 02:47, Vladlen Popolitov
> <v.popolitov@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.

Commits

  1. Get rid of our dependency on type "long" for memory size calculations.

  2. Use "ssize_t" not "long" in max_stack_depth-related code.

  3. Avoid integer overflow while testing wal_skip_threshold condition.