| From: | Robert Sanford <wobbet(at)gmail(dot)com> |
|---|---|
| To: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Segmentation Fault |
| Date: | 2023-09-14 13:27:03 |
| Message-ID: | CABa+nRs0x9DR52xyRa2COJOad-9VfjYQkDRcJOPACGsSCN_QJQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Woke up this morning excited to create a core dump and... it worked.
Not only does it work, it works fast. Query time dropped from 5.5s to 1.2s.
That was what I was hoping to get out of the VACUUM ANALYZE.
Very confused. I don't get it. I hope it doesn't happen again, but if it
does I'll get the core dump.
rjsjr
On Wed, Sep 13, 2023 at 6:58 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Sanford <wobbet(at)gmail(dot)com> writes:
> > I realized that when I was running GDB I just took a snap of when it
> > failed. Here I've added after continuing and requesting a backtrace.
>
> This is still quite unhelpful; it appears to show normal behavior in
> a process that's not the failing one. There is some advice about
> collecting useful backtraces at
>
>
> https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend
>
> I'd counsel the method of enabling core dumps and then attaching
> gdb to a core file, rather than dealing with live processes.
>
> regards, tom lane
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Flavin | 2023-09-14 13:57:17 | Re: BUG #18109: enable_partitionwise_aggregate does not apply when inserting or updating |
| Previous Message | David Rowley | 2023-09-14 11:49:34 | Re: BUG #18108: server process was terminated by signal 11: Segmentation fault |