Subject: Hello, novice Postgres user, seg fault investigation

From: James Creasy <[email-masked]>
Date: Wed, 24 Apr 2024 14:26:41 -0700

Hi,

Trying to figure out which list to post which types of questions to. New to
Postgres and the community so I thought I'd post an introduction.

We're also using the PostGIS extension for 3D data, PostgREST for the API,
socketio for push notifications. Deployed on AWS via Docker. We analyze 3D
data with incremental changes over year+ long time periods.

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?

We are setting up Postgres for debugging and see where we go from there.
Looks like gdb and valgrind are still the tools of choice. Lots to learn,
and that's where we are currently.

James
Bay Area, U.S.A

---

From: Tom Lane <[email-masked]>
Date: Wed, 24 Apr 2024 17:59:01 -0400

> 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: TIM CHILD <[email-masked]>
Date: Wed, 24 Apr 2024 15:08:36 -0700 (PDT)

James,
 
One of the effects of VACUUM is to update  table statistics. This provides information that  allows  query planner to better optimize your queries.  So assuming there is residual data already in the table before writing to it,  the  VACUUM that updated statistics may of changed your query plans. 
 
While the possibility of  changed query plans in no way explains the seg fault.  It may explain the change in behavior   the pre/post VACUUM.
 
In general without seeing more information regarding table structure, queries, table  indices,  query plans (pre/post) my answer is pure speculation.  It would also be beneficial to know what platform and version of Postgres, PostgREST and PostGIS you are running?
 
-Tim

> On 04/24/2024 2:26 PM PDT James Creasy <[email-masked]> wrote:
>  
>  
> Hi,
>  
> Trying to figure out which list to post which types of questions to. New to Postgres and the community so I thought I'd post an introduction. 
>  
> We're also using the PostGIS extension for 3D data, PostgREST for the API, socketio for push notifications. Deployed on AWS via Docker. We analyze 3D data with incremental changes over year+ long time periods.  
>  
> 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? 
>  
> We are setting up Postgres for debugging and see where we go from there. Looks like gdb and valgrind are still the tools of choice. Lots to learn, and that's where we are currently. 
>  
> James 
> Bay Area, U.S.A
>