Message-ID: <667292d5.050a0220.5b2f3.64e8@mx.google.com>
Sender: Michael Banck <mbanck@gmail.com>
Date: Wed, 19 Jun 2024 10:12:04 +0200
From: Michael Banck <mbanck@gmx.net>
To: Veerendra Pulapa <veerendra.pulapa@ashnik.com>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>,
	pgsql-admin <pgsql-admin@postgresql.org>,
	Achilleas Mantzios <a.mantzios@cloud.gatewaynet.com>,
	pgsql-admin@lists.postgresql.org
Subject: Re: Urgent: Segmentation Fault in PostgreSQL postmaster Process
References: 
 <CAND8iOsvP72D2XqHWPLOpDxBdzoZk_WK_u2KXbTRXHn+B6z-nQ@mail.gmail.com>
 <a477773e-c7ad-4dae-bb79-525f51069949@cloud.gatewaynet.com>
 <CAND8iOt6ZcvZ1rWsGYOcty9uQ_o-9XVk=+tPa7X8RFbGYUk=nA@mail.gmail.com>
 <6e6406c18726b29b5264c10dc548276dcd0173c0.camel@cybertec.at>
 <CAND8iOvnWs9aCYfxQy97wkYERAZVVEnUtnhqkDE6ph-c0o6QxQ@mail.gmail.com>
 <b59a2acb4b6f41a7d4be1f013a97eefcadd7bd36.camel@cybertec.at>
 <CAND8iOuNodr=p=t=Br_PmvGu0y3bvf9KEB_S0uTL0BO5DDeWRw@mail.gmail.com>
 <7ba5623c553d930c82a29ae346ea0ca29715d987.camel@cybertec.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <7ba5623c553d930c82a29ae346ea0ca29715d987.camel@cybertec.at>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: 
 <https://www.postgresql.org/message-id/667292d5.050a0220.5b2f3.64e8%40mx.google.com>
Precedence: bulk

Hi,

On Wed, Jun 19, 2024 at 10:08:14AM +0200, Laurenz Albe wrote:
> On Wed, 2024-06-19 at 13:32 +0530, Veerendra Pulapa wrote:
> > How do we check code 13.3 and 13.4  nbtdedup.c:800?
> > 
> > Regarding this issue can we get any relevant information? Where can we find bug information?
> 
> Huh?  PostgreSQL is open source.
> 
> I told you it is commit fa675af59f, so you can look at
> 
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=fa675af59f
> 
> It is also listed in the release notes of 13.4:
> https://www.postgresql.org/docs/13/release-13-4.html
> 
> - Harden B-tree posting list split code against corrupt data (Peter Geoghegan)
> 
>   Throw an error, rather than crashing, for an attempt to insert an item with a
>   TID identical to an existing entry. While that shouldn't ever happen, it has
>   been reported to happen when the index is inconsistent with its table.

Right, and the reason why the index is inconsistent with its table is
probably due to the ill-fated OS update you mentioned; if that was
in-place and unless you REINDEXed all the text-column-based indexes,
this might have lead to index corruption, so REINDEX your database after
you upgraded to the latest minor release of version 13.


Michael