Re: Index corruption issue after migration from RHEL 7 to RHEL 9 (PostgreSQL 11 streaming replication)

On Thu, Oct 23, 2025 at 11:21 AM Greg Sabino Mullane <htamfids(at)gmail(dot)com>
wrote:

>
>> -
>>
>> *Acceptable downtime:* ~1 day
>> -
>>
>> *Logical replication:* Not feasible due to the number of schemas,
>> tables, and overall data volume
>>
>> I'm not sure why this is not feasible. Can you expand on this?
>
> * For a *15 TB database* with roughly *1 day downtime*, what would be the
>> most reliable approach to migrate from *RHEL 7 → RHEL 9* while avoiding
>> collation/index corruption issues?
>
>
> pg_dump is the most reliable, and the slowest. Keep in mind that only the
> actual data needs to move over (not the indexes, which get rebuilt after
> the data is loaded). You could also mix-n-match pg_logical and pg_dump if
> you have a few tables that are super large. Whether either approach fits in
> your 24 hour window is hard to say without you running some tests.
>

Last year. I did a dump/restore of a 4.3TB (inclusive of indices; heavy on
poorly-compressible BYTEA) database from RHEL6 + 9.6.24 to RHEL 8 +
14.latest. It took just under 11 hours.

Gzip Level = 1
Remote database size: 4307406 MB
RemoteThreads: 16
LocalThreads: 24
SharedBuffs: 32 GB
MaintWorkMem: 3 GB
CheckPoint: 30 min
MaxWalSize: 36 GB
WalBuffs: 128 MB

Both systems were SAN-attached ESX VMs on the same virtual network

--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!