Message-ID: <69fea2cba0daafb07ec78ffb3b24b3d38f01cd2e.camel@cybertec.at>
Subject: Re: postgres server crash with "Segmentation fault"
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Ishan Arunkumar Joshi <ishan.joshi@netcracker.com>,
 "pgsql-admin@postgresql.org"
	 <pgsql-admin@postgresql.org>
Date: Fri, 17 Oct 2025 08:49:40 +0200
In-Reply-To: <1bef483a9e134bb595d3b25a35ac0e16@netcracker.com>
References: <1bef483a9e134bb595d3b25a35ac0e16@netcracker.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.56.2 (3.56.2-2.fc42) 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/69fea2cba0daafb07ec78ffb3b24b3d38f01cd2e.camel%40cybertec.at>
Precedence: bulk

On Thu, 2025-10-16 at 11:07 +0000, Ishan Arunkumar Joshi wrote:
> We are using PG16.9 in Patroni Postgres setup in production. Last night w=
e have face
> an issue [various data corruption errors]
>
> We had to drop the table =E2=80=9Cimpacted_table=E2=80=9D from database o=
nce the database is up.
>=20
> however we are not able to identify exact root cause behind =E2=80=9Csegm=
entation fault=E2=80=9D
> error for this table and need expert advice to find the root case and als=
o need
> suggestions to prevention steps.

By dropping the table, you have probably destroyed the evidence needed for =
that.
If you have a file system backup of the corrupted state, an expert might be=
 able
to identify probable causes.

One prevention step would have been to run the latest minor release (curren=
tly 16.10).

Other than that, make sure that you have a good backup that is occasionally=
 tested
and make sure that the backup is monitored (I have seen cases where the bac=
kup was a
daily pg_dump, and only when the corruption surfaced, people realized that =
the pg_dump
had been failing for the exact same reason...).

Yours,
Laurenz Albe