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

From Gregory Smith
Subject Re: Index corruption issue after migration from RHEL 7 to RHEL 9 (PostgreSQL 11 streaming replication)
Date
Msg-id CAHLJuCV5uoEjH+S7Wub7eRc7thcXtVZZNvYc1RyEC19Rx3V7Mw@mail.gmail.com
Whole thread Raw
In response to RE: Index corruption issue after migration from RHEL 7 to RHEL 9 (PostgreSQL 11 streaming replication)  (Scot Kreienkamp <Scot.Kreienkamp@la-z-boy.com>)
List pgsql-general
On Thu, Oct 23, 2025 at 4:24 PM Scot Kreienkamp <Scot.Kreienkamp@la-z-boy.com> wrote:


I always assumed streaming would “just work” as long as it’s the same major PG version and Linux-to-Linux regardless of OS/glibc version....It never occurred to me that there could be an OS influencing factor like the glibc version for streaming replication.


In addition to the locale checking when things are accessed, when you bring up a database cluster it checks some pg_controldata entries to make sure they match what the server's source code was built with.  If any of them are off, it won't run against those databases.

As a simple example that happens sometimes, if your main Linux PG install increased the block size changed at compile time, a different PG binary built with the default sizes will fail trying to read data from the modified one.  Because all these compile options have to match, sometimes you can't migrate a database built with one Linux distribution to another.  When that happens it's sometimes possible to hack together a custom build that matches the origin primary better, but now you're into packaging your own PG binaries.

pgsql-general by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: could not stat file "pg_wal/RECOVERYHISTORY": No such file or director
Next
From: hubert depesz lubaczewski
Date:
Subject: Why is this query touching 4gb of buffers?