MIME-Version: 1.0
References: <CAJ4rSwspyYBppQS701C=BVFX2yrP1JErgDCZXbC15BQh2zAS1Q@mail.gmail.com>
 <a2cd8084-b93e-4da0-8999-569a6e58ef6b.8f62f83c-ab51-428e-98d1-ab1abb243a49.a730880f-5287-4439-a814-c8637b50f48b@emailsignatures365.codetwo.com>
 <a2cd8084-b93e-4da0-8999-569a6e58ef6b.b1460fbe-55a2-4060-995f-39f4e2f3c7f9.1e3d3594-62a3-42b0-897b-6389e0f7ff72@emailsignatures365.codetwo.com>
 <CF431B1B-D105-4EC1-90DF-C25999455F04@gunduz.org> <SJ0PR15MB5245B6F64A2004F30004184E9AF0A@SJ0PR15MB5245.namprd15.prod.outlook.com>
In-Reply-To: <SJ0PR15MB5245B6F64A2004F30004184E9AF0A@SJ0PR15MB5245.namprd15.prod.outlook.com>
From: Gregory Smith <gregsmithpgsql@gmail.com>
Date: Fri, 24 Oct 2025 01:34:43 -0400
Message-ID: <CAHLJuCV5uoEjH+S7Wub7eRc7thcXtVZZNvYc1RyEC19Rx3V7Mw@mail.gmail.com>
Subject: Re: Index corruption issue after migration from RHEL 7 to RHEL 9
 (PostgreSQL 11 streaming replication)
To: Scot Kreienkamp <Scot.Kreienkamp@la-z-boy.com>
Cc: =?UTF-8?B?RGV2cmltIEfDvG5kw7x6?= <devrim@gunduz.org>, 
	"pgsql-general@lists.postgresql.org" <pgsql-general@lists.postgresql.org>, Bala M <krishna.pgdba@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000d1ffd80641e0e873"
Archived-At: <https://www.postgresql.org/message-id/CAHLJuCV5uoEjH%2BS7Wub7eRc7thcXtVZZNvYc1RyEC19Rx3V7Mw%40mail.gmail.com>
Precedence: bulk

--000000000000d1ffd80641e0e873
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 23, 2025 at 4:24=E2=80=AFPM Scot Kreienkamp <
Scot.Kreienkamp@la-z-boy.com> wrote:

>
> I always assumed streaming would =E2=80=9Cjust work=E2=80=9D as long as i=
t=E2=80=99s 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 th=
e
> 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.

--000000000000d1ffd80641e0e873
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Thu, Oct 23, 2025 at 4:24=E2=80=AFPM S=
cot Kreienkamp &lt;<a href=3D"mailto:Scot.Kreienkamp@la-z-boy.com">Scot.Kre=
ienkamp@la-z-boy.com</a>&gt; wrote:</div><div class=3D"gmail_quote gmail_qu=
ote_container"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=
=3D"msg9117576551693042984">


<div lang=3D"EN-US" style=3D"overflow-wrap: break-word;">
<div class=3D"m_9117576551693042984WordSection1">
<p class=3D"MsoNormal"><br>I always assumed streaming would =E2=80=9Cjust w=
ork=E2=80=9D as
 long as it=E2=80=99s the same major PG version and Linux-to-Linux regardle=
ss of OS/glibc version....It never occurred to me that there could be an OS=
 influencing factor like the glibc
 version for streaming replication.</p></div></div></div></blockquote><div>=
<br></div><div>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&#39;s source code was built with.=
=C2=A0 If any of them are off, it won&#39;t run against those databases.</d=
iv><div><br></div><div>As a simple example that happens sometimes, if your =
main Linux PG install increased the block size changed at compile time, a d=
ifferent PG binary built with the default sizes will fail trying to read da=
ta from the modified one.=C2=A0 Because all these compile options have to m=
atch, sometimes you can&#39;t migrate a database built with one Linux distr=
ibution to another.=C2=A0 When that happens it&#39;s sometimes possible to =
hack together a custom build that matches the origin primary better, but no=
w you&#39;re into packaging your own PG binaries.</div><div><br></div></div=
></div>

--000000000000d1ffd80641e0e873--