v.popolitov@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.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.
Hi everyone.
The patch added to Commitfest:
https://commitfest.postgresql.org/50/5343/
--
Best regards,
Vladlen Popolitov.
