public inbox for [email protected]
help / color / mirror / Atom feedHello, novice Postgres user, seg fault investigation
3+ messages / 3 participants
[nested] [flat]
* Hello, novice Postgres user, seg fault investigation
@ 2024-04-24 21:26 James Creasy <[email protected]>
2024-04-24 21:59 ` Re: Hello, novice Postgres user, seg fault investigation Tom Lane <[email protected]>
2024-04-24 22:08 ` Re: Hello, novice Postgres user, seg fault investigation TIM CHILD <[email protected]>
0 siblings, 2 replies; 3+ messages in thread
From: James Creasy @ 2024-04-24 21:26 UTC (permalink / raw)
To: [email protected]
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
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Hello, novice Postgres user, seg fault investigation
2024-04-24 21:26 Hello, novice Postgres user, seg fault investigation James Creasy <[email protected]>
@ 2024-04-24 21:59 ` Tom Lane <[email protected]>
1 sibling, 0 replies; 3+ messages in thread
From: Tom Lane @ 2024-04-24 21:59 UTC (permalink / raw)
To: James Creasy <[email protected]>; +Cc: [email protected]
James Creasy <[email protected]> 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
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Hello, novice Postgres user, seg fault investigation
2024-04-24 21:26 Hello, novice Postgres user, seg fault investigation James Creasy <[email protected]>
@ 2024-04-24 22:08 ` TIM CHILD <[email protected]>
1 sibling, 0 replies; 3+ messages in thread
From: TIM CHILD @ 2024-04-24 22:08 UTC (permalink / raw)
To: [email protected]
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 protected]> 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
>
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2024-04-24 22:08 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-04-24 21:26 Hello, novice Postgres user, seg fault investigation James Creasy <[email protected]>
2024-04-24 21:59 ` Tom Lane <[email protected]>
2024-04-24 22:08 ` TIM CHILD <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox