| From: | Andrei Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru> |
|---|---|
| To: | alexey(dot)ermakov(at)dataegret(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org, PG Bug reporting form <noreply(at)postgresql(dot)org> |
| Subject: | Re: BUG #18349: ERROR: invalid DSA memory alloc request size 1811939328, CONTEXT: parallel worker |
| Date: | 2024-02-16 14:40:03 |
| Message-ID: | 512ef568-336e-4087-ba23-f22b006d329d@postgrespro.ru |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On 16/2/2024 20:18, PG Bug reporting form wrote:
> Interesting thing: after query fails it take some time (seconds) before psql
> gives control back.
> It turns out that postgresql written 1M+ (!) temporary files (most of them
> are empty) and cleaning up takes some time.
Interesting. It correlates with one performance issue I have been trying
to catch already 3 months. Could you provide some reproduction of that
behavior?
> With bigger work_mem it won't write so many files. Maybe memory issue
> somehow related with number of files.
>
> In PostgreSQL 16.2 there were fix for similar bug: [1],[2]. Could it be that
> there is some issue with it ?
Looks like surely the same issue we fixed recently: Parallel Hash Join +
DSM is a sign of that problem.
--
regards,
Andrei Lepikhov
Postgres Professional
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2024-02-16 20:50:41 | BUG #18350: Modifying predefined roles' unlimited connections for VA STIG cybersecurity checklist |
| Previous Message | PG Bug reporting form | 2024-02-16 13:18:42 | BUG #18349: ERROR: invalid DSA memory alloc request size 1811939328, CONTEXT: parallel worker |