Vladlen Popolitov writes:
> Only one exceptions in src/backend/commands/vacuumparallel.c:378
> shared->dead_items_info.max_bytes = vac_work_mem * (size_t)1024;
> max_bytes declared as size_t, I did cast to the same type (I cannot
> guarranty, that size_t and Size are equivalent in all systems)
I
Tom Lane писал(а) 2025-01-24 06:13:
v.popoli...@postgrespro.ru writes:
[ v2-0001-work_mem_vars-limit-increased-in-64bit-Windows.patch ]
Hi Tom,
Thank you for the interest to the patch and comments.
Comment A.
Is there a reason not to do them all the same way? I'd suggest
"(Size) 1024", losi
Tom Lane писал(а) 2025-01-24 06:13:
v.popoli...@postgrespro.ru writes:
[ v2-0001-work_mem_vars-limit-increased-in-64bit-Windows.patch ]
Hi Tom,
Thank you for the interest to the patch and comments.
Comment A.
Is there a reason not to do them all the same way? I'd suggest
"(Size) 1024", losi
v.popoli...@postgrespro.ru writes:
> [ v2-0001-work_mem_vars-limit-increased-in-64bit-Windows.patch ]
I took a brief look at this. I think it's generally going in the
right direction, but you seem to be all over the place on how
you are doing the casts:
+ if (metadata->nPendingPages * GIN_
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
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 at
David Rowley писал(а) 2024-09-24 01:07:
On Tue, 24 Sept 2024 at 02:47, Vladlen Popolitov
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 at once.
I think, it will take about 1 week to fix and tes
David Rowley писал(а) 2024-09-24 01:07:
On Tue, 24 Sept 2024 at 02:47, Vladlen Popolitov
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 at once.
I think, it will take about 1 week to fix and tes
On Tue, 24 Sept 2024 at 02:47, Vladlen Popolitov
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 at once.
> I think, it will take about 1 week to fix and test all changes. I will
> estimate the
David Rowley писал(а) 2024-09-23 15:35:
On Mon, 23 Sept 2024 at 21:01, Vladlen Popolitov
wrote:
Thank you for proposal, I looked at the patch and source code from
this
point of view. In this approach we need to change all .
I counted the appearences of these vars in the code:
maintenance_work_
On Mon, 23 Sept 2024 at 21:01, Vladlen Popolitov
wrote:
> Thank you for proposal, I looked at the patch and source code from this
> point of view. In this approach we need to change all .
> I counted the appearences of these vars in the code:
> maintenance_work_mem appears 63 times in 20 files
> w
David Rowley писал(а) 2024-09-23 04:28:
On Fri, 20 Sept 2024 at 01:55, Пополитов Владлен
wrote:
Currently PostgreSQL built on 64-bit Windows has 2Gb limit for
GUC variables due to sizeof(long)==4 used by Windows compilers.
Technically 64-bit addressing for maintenance_work_mem is possible,
but
On Fri, 20 Sept 2024 at 01:55, Пополитов Владлен
wrote:
> Currently PostgreSQL built on 64-bit Windows has 2Gb limit for
> GUC variables due to sizeof(long)==4 used by Windows compilers.
> Technically 64-bit addressing for maintenance_work_mem is possible,
> but code base historically uses variabl
Hello!
Currently PostgreSQL built on 64-bit Windows has 2Gb limit for
GUC variables due to sizeof(long)==4 used by Windows compilers.
Technically 64-bit addressing for maintenance_work_mem is possible,
but code base historically uses variables and constants of type "long",
when process maintenanc
13 matches
Mail list logo
