Re: Increase of maintenance_work_mem limit in 64-bit Windows
Vladlen Popolitov <v.popolitov@postgrespro.ru>
From: Vladlen Popolitov <v.popolitov@postgrespro.ru>
To: David Rowley <dgrowleyml@gmail.com>
Cc: pgsql-hackers@postgresql.org
Date: 2024-09-24T07:19:13Z
Lists: pgsql-hackers
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. 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.
Commits
-
Get rid of our dependency on type "long" for memory size calculations.
- 041e8b95b8cd 18.0 landed
-
Use "ssize_t" not "long" in max_stack_depth-related code.
- b9d232b9de89 18.0 landed
-
Avoid integer overflow while testing wal_skip_threshold condition.
- b9aa4166fa38 18.0 landed
- f7a08b6e96ee 16.7 landed
- b296e55b4272 15.11 landed
- 6a33bb35c041 14.16 landed
- 49a38238e2b6 13.19 landed
- 1e25cdb21454 17.3 landed