Re: Pass heap tuple counts to parallel vacuum as double

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Baji Shaik <baji(dot)pgdev(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Pass heap tuple counts to parallel vacuum as double
Date: 2026-11-10 01:46:12
Message-ID: CAD21AoCHY3vNb0b57+yz8qcBuF9QHrXf6M-pO8mVEQgZ+d19+g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Nov 9, 2026 at 3:16 PM Baji Shaik <baji(dot)pgdev(at)gmail(dot)com> wrote:
>
> Hi,
>
> I noticed that parallel_vacuum_bulkdel_all_indexes() and
> parallel_vacuum_cleanup_all_indexes() take the heap tuple count as long,
> while lazy vacuum passes a double and vacuumparallel.c stores it as a
> double in shared memory for the index AMs. Where long is 32 bits, as on
> Windows, a table with more than about 2.1 billion tuples gets a wrong
> num_heap_tuples only when its indexes are vacuumed in parallel. It's
> rare in practice, but the serial path has no such limit.
>
> The attached patch changes the parameter to double.

Thank you for the report. The change looks good to me. I’m going to
push it to master only, barring objections. Although it’s an oversight
in commit 8e1fae193864, it can’t be backpatched, since it changes the
function signatures.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tender Wang 2026-11-10 02:06:37 Backend crash in expanded_record_info functions
Previous Message João Rito 2026-11-10 01:40:03 Re: Warn when creating or enabling a subscription with max_logical_replication_workers = 0