| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | James Creasy <james(at)buildtrue(dot)io> |
| Cc: | pgsql-novice(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Hello, novice Postgres user, seg fault investigation |
| Date: | 2024-04-24 21:59:01 |
| Message-ID: | 3769211.1713995941@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-novice |
James Creasy <james(at)buildtrue(dot)io> writes:
> Now the interesting part, we're getting a seg fault which goes away when we
> run VACUUM on the table before writing to it, which is perplexing as the
> table can be newly created and contains a few hundred rows. How could the
> db get into a fatal state so quickly?
If you didn't find it already, there's some advice here:
https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend
With so many moving parts, it's hard to guess whether the bug is in
Postgres or PostGIS or what, but a stack trace should be informative.
Also, as that page mentions, it's a good idea to make sure you
are on latest release(s) before you spend time digging.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | TIM CHILD | 2024-04-24 22:08:36 | Re: Hello, novice Postgres user, seg fault investigation |
| Previous Message | James Creasy | 2024-04-24 21:26:41 | Hello, novice Postgres user, seg fault investigation |