MIME-Version: 1.0
From: James Creasy <james@buildtrue.io>
Date: Wed, 24 Apr 2024 14:26:41 -0700
Message-ID: 
 <CADN1ADcgWN+kWEeCmQ4pwx91PjAXjYuYYunSArw9cyvDW8ZeZg@mail.gmail.com>
Subject: Hello, novice Postgres user, seg fault investigation
To: pgsql-novice@lists.postgresql.org
Content-Type: multipart/alternative; boundary="0000000000003a5a8a0616de5446"
Archived-At: 
 <https://www.postgresql.org/message-id/CADN1ADcgWN%2BkWEeCmQ4pwx91PjAXjYuYYunSArw9cyvDW8ZeZg%40mail.gmail.com>
Precedence: bulk

--0000000000003a5a8a0616de5446
Content-Type: text/plain; charset="UTF-8"

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

--0000000000003a5a8a0616de5446
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br></div><div>Trying to figure out which list to =
post which types of questions to. New to Postgres and the community so I th=
ought I&#39;d post an introduction.=C2=A0</div><div><br></div><div>We&#39;r=
e also using the PostGIS extension for 3D data, PostgREST for the API, sock=
etio for push notifications. Deployed on AWS via Docker. We analyze 3D data=
 with incremental changes over year+ long time periods.=C2=A0=C2=A0</div><d=
iv><br></div><div>Now the interesting part, we&#39;re getting a seg fault w=
hich 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?=C2=A0</div><div><=
br></div><div>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&#39;s where we are currently.=C2=A0</div><div><br></div=
><div>James=C2=A0</div><div>Bay Area, U.S.A</div></div>

--0000000000003a5a8a0616de5446--