Le sam. 6 mai 2023 à 15:15, Ron <ronljohnso...@gmail.com> a écrit :
> On 5/6/23 07:19, Marc Millas wrote: > > > > Le sam. 6 mai 2023 à 09:46, Peter J. Holzer <hjp-pg...@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 > > -- > Born in Arizona, moved to Babylonia. >
