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 <james@buildtrue.io> 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