From: Tom Lane <tgl@sss.pgh.pa.us>
To: James Creasy <james@buildtrue.io>
cc: pgsql-novice@lists.postgresql.org
Subject: Re: Hello, novice Postgres user, seg fault investigation
In-reply-to: 
 <CADN1ADcgWN+kWEeCmQ4pwx91PjAXjYuYYunSArw9cyvDW8ZeZg@mail.gmail.com>
References: 
 <CADN1ADcgWN+kWEeCmQ4pwx91PjAXjYuYYunSArw9cyvDW8ZeZg@mail.gmail.com>
Comments: In-reply-to James Creasy <james@buildtrue.io>
	message dated "Wed, 24 Apr 2024 14:26:41 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3769210.1713995941.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 24 Apr 2024 17:59:01 -0400
Message-ID: <3769211.1713995941@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3769211.1713995941%40sss.pgh.pa.us>
Precedence: bulk

James Creasy <james@buildtrue.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 th=
e
> 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