From: | Radu Radutiu <rradutiu(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Postgresql OOM |
Date: | 2024-06-10 13:13:06 |
Message-ID: | CAG4TxrgQ5V00eYTaRhPUbfp8Gnhzr4i2YooMGOhXW8U6RMmzNA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
>
> FWIW, it can be useful to configure the OS with strict memory overcommit.
> That
> causes postgres to fail more gracefully, because the OOM killer won't be
> invoked.
>
In the current setup the database is used as an embedded db, with the
application sharing the same host as the database. Setting the memory
overcommit affects the other application, but configuring LimitAS for the
postgresql systemd service should work.
Does this mean that the fact that this query uses more than 100x the
configured work_mem is not considered a bug? Should I create a bug report?
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2024-06-10 13:14:59 | Re: Reuse child_relids in try_partitionwise_join was Re: Assert failure on bms_equal(child_joinrel->relids, child_joinrelids) |
Previous Message | Andrew Dunstan | 2024-06-10 12:58:49 | Non-text mode for pg_dumpall |