Re: Fix overflow of nbatch
Konstantin Knizhnik <knizhnik@garret.ru>
From: Konstantin Knizhnik <knizhnik@garret.ru>
To: Tomas Vondra <tomas@vondra.me>, David Rowley <dgrowleyml@gmail.com>
Cc: Vaibhav Jain <jainva@google.com>, pgsql-hackers@postgresql.org,
Madhukar <madhukarprasad@google.com>,
Sangeetha Seshadri <sangsesh@google.com>
Date: 2025-09-23T19:13:54Z
Lists: pgsql-hackers
On 23/09/2025 6:11 PM, Tomas Vondra wrote: > 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 > Hi Tomas, If you are going to investigate this problem more, can you also look at the related problem: https://www.postgresql.org/message-id/flat/52b94d5b-a135-489d-9833-2991a69ec623%40garret.ru#ebe4151f1d505bbcc32cf93b2e8a1936 I proposed the patch but got no feedback. Best regards, Konstantin