From: | Tomas Vondra <tomas(at)vondra(dot)me> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | Vaibhav Jain <jainva(at)google(dot)com>, pgsql-hackers(at)postgresql(dot)org, Madhukar <madhukarprasad(at)google(dot)com>, Sangeetha Seshadri <sangsesh(at)google(dot)com> |
Subject: | Re: Fix overflow of nbatch |
Date: | 2025-09-23 15:11:06 |
Message-ID: | 2bb6de88-722e-438b-a952-3c947ab56998@vondra.me |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
I kept looking at this, and unfortunately the it seems a bit worse :-(
Fixing the overflow is easy enough - adding the cast does the trick.
But then there's the second issue I mentioned - the loop does not adjust
the hash_table_bytes. It updates the *space_allowed, but that's not what
the current_space/new_space formulas use.
This breaks the "balancing" as the nbatch gets decreased until
nbatch <= (work_mem / BLCKSZ)
while the hash table "space_allowed" is increasing. This may result in
an *increased* memory usage :-(
I also noticed the code does not clamp nbuckets properly as it should.
The question what to do about this. If we got this a week ago, I'd just
probably just revert a1b4f289, and then try again for PG19. After all,
the issue it meant to address is somewhat rare.
But with 18 already stamped ...
I've shared these findings with the rest of the RMT, I'll see what their
thoughts are. Of course, other opinions/suggestions are welcome.
regards
--
Tomas Vondra
From | Date | Subject | |
---|---|---|---|
Next Message | Srirama Kucherlapati | 2025-09-23 15:28:58 | RE: AIX support |
Previous Message | Álvaro Herrera | 2025-09-23 15:11:04 | Re: Invalid primary_slot_name triggers warnings in all processes on reload |