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.
On Mon, Jun 24, 2024 at 10:10 AM Muhammad Waqas <waqas.m@xxxxxxxxxxx> wrote:
yes you can2024년 6월 22일 (토) 오전 11:38, Veerendra Pulapa <veerendra.pulapa@xxxxxxxxxx>님이 작성:Hi All,Is there any way to reproduce the issue on different OS and Different DB versions?On Wed, Jun 19, 2024 at 1:42 PM Michael Banck <mbanck@xxxxxxx> 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.
