Re: Fix overflow of nbatch
От | David Rowley |
---|---|
Тема | Re: Fix overflow of nbatch |
Дата | |
Msg-id | CAApHDvoMx=xL4DHzcF1WQ+LObdVPhX_dRcXRahAdukEw8aODoQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Fix overflow of nbatch (Tomas Vondra <tomas@vondra.me>) |
Ответы |
Re: Fix overflow of nbatch
|
Список | pgsql-hackers |
On Tue, 23 Sept 2025 at 13:01, Tomas Vondra <tomas@vondra.me> wrote: > > On 9/23/25 02:02, David Rowley wrote: > > Ok cool. We're just in the freeze for 18.0 at the moment. Once that's > > over, should I take care of this, or do you want to? > > > > Feel free to fix, but I can take care of it once 18 is out the door. > It's my bug, after all. > > BTW ExecHashIncreaseBatchSize needs the same fix, I think. I think it's probably best you handle this. I didn't notice that one. You know this area much better than I do. > I wonder how likely the overflow is. AFAICS we'd need nbatch=256k (with > 8KB blocks), which is a lot. But with the balancing logic, it'd also > mean each batch is about ~2GB. So the whole "hash table" would be about > 500GB. Possible, but unlikely. I think no matter how low the chances of overflow are, the code isn't written the way it was intended to be, so it should just be put the way it was intended to be without question of the likelihood of overflow. Otherwise, we'll just end up with harder to hit bugs which could take much longer to [re]discover. Also, in these terms, what's unlikely today may not be in the future. David
В списке pgsql-hackers по дате отправления: