Re: Index corruption issue after migration from RHEL 7 to RHEL 9 (PostgreSQL 11 streaming replication) - Mailing list pgsql-general

From Adrian Klaver
Subject Re: Index corruption issue after migration from RHEL 7 to RHEL 9 (PostgreSQL 11 streaming replication)
Date
Msg-id b465b0d4-5516-46e0-8a60-e24a05169566@aklaver.com
Whole thread Raw
In response to Re: Index corruption issue after migration from RHEL 7 to RHEL 9 (PostgreSQL 11 streaming replication)  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: Index corruption issue after migration from RHEL 7 to RHEL 9 (PostgreSQL 11 streaming replication)
List pgsql-general
On 10/24/25 18:06, David Rowley wrote:
> On Sat, 25 Oct 2025 at 13:40, Adrian Klaver <adrian.klaver@aklaver.com> wrote:
>>

>> 2) The attitude comes from lessons learned in the School of Hard Knocks.
>> Until someone or someones can guarantee a new GA release will not eat
>> your data or spring security leaks then the prudent thing to do is wait
>> to see what happens when it hits the world at large. I learned this
>> lesson, pitfalls of jumping into something new, across fields outside of
>> software as well. In other words 'new and improved' is not always the
>> case, see 737 MAX as case in point.
> 
> I don't see why this reason is applicable at all to my statement. I
> didn't state that everyone should go and run with .0. I said we
> shouldn't encourage people to test beta and RC versions, as if they
> don't do that then .0 won't be as stable as if they did test (and
> report issues). It seems like simple cause and effect to me.

I am not following, from your previous post:

"Beta versions are meant for test instances. It'd be
good if people encouraged their use more often rather than pushing
people to defer til GA"

That seems to be the opposite of what you say above.

> 
>> 3) Progress happens and you need to keep up. A little caution is good
>> thing though, especially if you are the one who is being held
>> responsible for any adverse outcomes.
> 
> We're talking test servers here. I assume they can be recreated
> without too much trouble.

Yes, but the OP was talking about upgrading a production database 
directly to 18. That was what my reply was referring to and what I was 
counseling against.

> 
> David


-- 
Adrian Klaver
adrian.klaver@aklaver.com



pgsql-general by date:

Previous
From: David Rowley
Date:
Subject: Re: Index corruption issue after migration from RHEL 7 to RHEL 9 (PostgreSQL 11 streaming replication)
Next
From: David Rowley
Date:
Subject: Re: Index corruption issue after migration from RHEL 7 to RHEL 9 (PostgreSQL 11 streaming replication)