| From: | Gregory Smith <gregsmithpgsql(at)gmail(dot)com> |
|---|---|
| To: | Scot Kreienkamp <Scot(dot)Kreienkamp(at)la-z-boy(dot)com> |
| Cc: | Devrim Gündüz <devrim(at)gunduz(dot)org>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>, Bala M <krishna(dot)pgdba(at)gmail(dot)com> |
| Subject: | Re: Index corruption issue after migration from RHEL 7 to RHEL 9 (PostgreSQL 11 streaming replication) |
| Date: | 2025-10-24 05:34:43 |
| Message-ID: | CAHLJuCV5uoEjH+S7Wub7eRc7thcXtVZZNvYc1RyEC19Rx3V7Mw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Thu, Oct 23, 2025 at 4:24 PM Scot Kreienkamp <
Scot(dot)Kreienkamp(at)la-z-boy(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | hubert depesz lubaczewski | 2025-10-24 11:01:48 | Why is this query touching 4gb of buffers? |
| Previous Message | Laurenz Albe | 2025-10-24 04:59:43 | Re: could not stat file "pg_wal/RECOVERYHISTORY": No such file or director |