From: | Ron <ronljohnsonjr(at)gmail(dot)com> |
---|---|
To: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Death postgres |
Date: | 2023-05-06 13:15:04 |
Message-ID: | 38505370-ecbd-3af3-bcff-4cf2ec4903ff@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 5/6/23 07:19, Marc Millas wrote:
>
>
> Le sam. 6 mai 2023 à 09:46, Peter J. Holzer <hjp-pgsql(at)hjp(dot)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.
--
Born in Arizona, moved to Babylonia.
From | Date | Subject | |
---|---|---|---|
Next Message | Marc Millas | 2023-05-06 13:49:34 | Re: Death postgres |
Previous Message | Evgeny Morozov | 2023-05-06 12:29:36 | Re: "PANIC: could not open critical system index 2662" - twice |