Re: Increase of maintenance_work_mem limit in 64-bit Windows

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Vladlen Popolitov <v(dot)popolitov(at)postgrespro(dot)ru>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Increase of maintenance_work_mem limit in 64-bit Windows
Date: 2025-01-31 19:00:49
Message-ID: 3944694.1738350049@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Vladlen Popolitov <v(dot)popolitov(at)postgrespro(dot)ru> 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 direct your attention to c.h:

/*
* Size
* Size of any memory resident object, as returned by sizeof.
*/
typedef size_t Size;

It used to be possible for them to be different types, but not
anymore. But I take your point that using "size_t" instead
makes sense if that's how the target variable is declared.
(And I feel no need to replace size_t with Size or vice versa
in code that's already correct.)

>> I wonder if it'd be worth creating a macro rather than repeating
>> "* (Size) 1024" everywhere. KILOBYTES_TO_BYTES(work_mem) seems
>> too wordy, but maybe we can think of a shorter name.

I agree that this wasn't such a great idea, mainly because we did
not end up using exactly "Size" everywhere.

> 1) sort_mem_bytes is used as int64 variable later, passed to
> function with int64 parameter. "Size" type is not used in
> this case.
> 2) work_mem_bytes is compared only with double values later, it
> does not need additional casts in this case. "Size" type is not
> used in this case.

Agreed on these.

> Agree. It was "double" due to usage of this variable as parameter
> in tbm_calculate_entries(double maxbytes), but really
> tbm_calculate_entries() does not need this type, it again
> converted to "long" local variable. I changed parameter,
> local variable and return value of tbm_calculate_entries()
> to Size.

Agreed on the parameter being Size, but I made the return type
be int to emphasize that we're restricting the result to
integer range. (It looks like additional work would be needed
to let it exceed INT_MAX; if anyone ever feels like doing that
work, they can change the result type again.)

> Also tbm_calculate_entries() is used in assignment to "long"
> variable maxentries.

I concluded there that we should make maxentries "double",
on the same reasoning as you have above: it's only used in
calculations with other double variables.

Pushed with some minor additional cleanups. Many thanks for
working on this! It was a TODO for ages.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sami Imseih 2025-01-31 19:27:14 Re: pgbench with partitioned tables
Previous Message Masahiko Sawada 2025-01-31 18:49:48 Re: UUID v7