Re: Increase of maintenance_work_mem limit in 64-bit Windows

From: Vladlen Popolitov <v(dot)popolitov(at)postgrespro(dot)ru>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Increase of maintenance_work_mem limit in 64-bit Windows
Date: 2024-09-24 07:19:13
Message-ID: eefa7b068394f368afd80f50fbb249eb@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Rowley писал(а) 2024-09-24 01:07:
> On Tue, 24 Sept 2024 at 02:47, Vladlen Popolitov
> <v(dot)popolitov(at)postgrespro(dot)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.
Yes. It is what I mean, when I wrote about the context - in this case
variable is used in "Size" context and the cast to Size type should be
used. It is why I need to check all places in code. I am going to do it
during this week.

--
Best regards,

Vladlen Popolitov.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2024-09-24 07:57:28 Re: Normalize queries starting with SET for pg_stat_statements
Previous Message Zhijie Hou (Fujitsu) 2024-09-24 07:14:53 RE: Conflict detection for update_deleted in logical replication