Le sam. 6 mai 2023 à 09:46, Peter J. Holzer <hjp-pgsql@hjp.at> a écrit :
On 2023-05-06 03:14:20 +0200, Marc Millas wrote: > postgres 14.2 on Linux redhat > > temp_file_limit set around 210 GB. > > a select request with 2 left join have crashed the server (oom killer) after > the postgres disk occupation did grow from 15TB to 16 TB.
"15TB" and "16TB" are pretty low-resolution. For example, 15.4TB rounds down to 15TB, while 15.6TB rounds up to 16TB, while they are in fact only 200GB apart.
Heck, even 15.4TB and 15.6TB are low-resolution. temp_file_limit may actually be working.
temp_file_limit limits the space a process may use on disk while the OOM killer gets activated when the system runs out of RAM. So these seem to be unrelated.
hp
Its clear that oom killer is triggered by RAM and temp_file is a disk thing...
But the sudden growth of disk space usage and RAM did happen exactly at the very same time, with only one user connected, and only one query running...
If your question is about temp_file_limit, don't distract us with OOM issues.
My question is how postgres can use space without caring about temp_file_limit. The oom info is kind of hint about the context as, as said, one select did generate both things
