| From: | Cameron Vogt <cvogt(at)automaticcontrols(dot)net> |
|---|---|
| To: | Tomas Vondra <tomas(at)vondra(dot)me>, Michael Paquier <michael(at)paquier(dot)xyz>, Sean Massey <sean(dot)f(dot)massey(at)gmail(dot)com> |
| Cc: | "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: PostgreSQL 17 Segmentation Fault |
| Date: | 2024-10-04 22:17:47 |
| Message-ID: | BY5PR16MB31442E3DF22944637E46F71EAB722@BY5PR16MB3144.namprd16.prod.outlook.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
The query crashes less than a second after running it, so there isn't much time to consume memory or to try attaching GDB mid-query. I tried decreasing work_mem from 32MB to 128kB, but I still get the error. I've also ran vacuum and analyze to no avail. When the query is successful, it only yields 68 rows, so I don't think the row estimates are too far off. I checked the files you mentioned for memory overcommit:
/proc/sys/vm/overcommit_memory = 0
/proc/sys/vm/overcommit_kbytes = 0
/proc/sys/vm/overcommit_ratio = 50
The free RAM on the system starts at and hangs around 8GB while executing the crashing query.
The only two things that have fixed the issue so far: Turning JIT off or decreasing shared_buffers. I suppose then that it might be a JIT issue?
Cameron Vogt | Software Developer
Direct: 314-756-2302 | Cell: 636-388-2050
1585 Fencorp Drive | Fenton, MO 63026
Automatic Controls Equipment Systems, Inc.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Munro | 2024-10-05 01:16:31 | Re: [EXTERNAL] Re: Windows Application Issues | PostgreSQL | REF # 48475607 |
| Previous Message | Tomas Vondra | 2024-10-04 19:11:15 | Re: PostgreSQL 17 Segmentation Fault |