| 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
| 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 |