Re: Urgent: Segmentation Fault in PostgreSQL postmaster Process

Dear All,

I hope this message finds you well.

I am reaching out to discuss an issue we recently encountered with our
PostgreSQL setup, where a bug triggered on our standby servers before it
affected the master. I am seeking insights into whether the resource
differences between our servers could have played a role in this sequence
of events.

*Issue Overview:*

- We observed a signal 11 (segmentation fault) error that first appeared
on our standby servers and subsequently affected the master server.
- Our setup consists of a master server with higher resources and
multiple standby servers with relatively lower resources.

*Concerns:*

- The standby servers have fewer resources compared to the master, which
may have contributed to the bug being triggered on them first?
- We are considering whether the disparity in resources could lead to
performance bottlenecks or stability issues, causing the standby servers to
encounter the bug earlier than the master?

*Request for Insights:*

- Has anyone else experienced similar issues where bugs or faults are
observed on standby servers before the master?
- Could the resource differences between the master and standby servers
play a significant role in this behavior?
- Are there best practices for ensuring stability across servers with
different resource allocations, especially in a High Availability (HA)
setup?

I would greatly appreciate any insights, experiences, or suggestions you
might have regarding this issue. Understanding the underlying reasons will
help us optimize our setup and prevent future occurrences.

Thank you for your time and expertise.
Br,
Veerendra Pulapa | Technical Consultant
M: +91-9949349894 | www.ashnik.com

<https://www.linkedin.com/company/ashnik-pte-ltd/>
<https://www.facebook.com/AshnikBiz>
<https://www.youtube.com/user/ashnikbiz>
<https://www.instagram.com/ashnikbiz/> <https://twitter.com/Ashnikbiz>

On Mon, Jun 24, 2024 at 10:10 AM Muhammad Waqas <waqas(dot)m(at)bitnine(dot)net> wrote:

> yes you can
>
> 2024년 6월 22일 (토) 오전 11:38, Veerendra Pulapa <veerendra(dot)pulapa(at)ashnik(dot)com>님이
> 작성:
>
>> Hi All,
>>
>> Is there any way to reproduce the issue on different OS and Different DB
>> versions?
>>
>> Br,
>> Veerendra Pulapa | Technical Consultant
>> M: +91-9949349894 | www.ashnik.com
>>
>>
>> <https://www.linkedin.com/company/ashnik-pte-ltd/>
>> <https://www.facebook.com/AshnikBiz>
>> <https://www.youtube.com/user/ashnikbiz>
>> <https://www.instagram.com/ashnikbiz/> <https://twitter.com/Ashnikbiz>
>>
>>
>> On Wed, Jun 19, 2024 at 1:42 PM Michael Banck <mbanck(at)gmx(dot)net> wrote:
>>
>>> 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
>>>
>>
>>
>> *______________________________________________________________________________________This
>> email may contain confidential, privileged or copyright material and is
>> solely for the use of the intended recipient(s). If you are not the
>> rightful recipient of this email, please delete this email immediately and
>> inform the recipient. *
>>
>>

--

*________________________________________________________________________________________
*_This email may contain confidential, privileged or copyright material and
is solely for the use of the intended recipient(s). If you are not the
rightful recipient of this email, please delete this email immediately and
inform the recipient. 
_
*
*