Postgres Upgrade Issues with pg_upgrade

Question

I am trying to upgrade 9.5.5 to 12.3 using pg_uprade, got the following error

Old and new pg_controldata maximum relation segment sizes are invalid or do not match

9.5.5

Blocks per segment of large relation: 8388608

12.3

Blocks per segment of large relation: 131072

8388608 blocks is equivalent to 64 GB.

I recompiled the 12.3 version using the following options

./configure --prefix=/opt/pgsql/PostgreSQL-12 --with-segsize=64

pg_controldata output 9.5.5

pg_control version number: 942
Catalog version number: 201510051
Database system identifier: 6307574991682851055
Database cluster state: shut down
pg_control last modified: Thu 01 Oct 2020 07:15:50 PM EDT
Latest checkpoint location: 2FB/7C000028
Prior checkpoint location: 2FB/78000098
Latest checkpoint's REDO location: 2FB/7C000028
Latest checkpoint's REDO WAL file: 00000001000002FB0000001F
Latest checkpoint's TimeLineID: 1
Latest checkpoint's PrevTimeLineID: 1
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID: 0/130082037
Latest checkpoint's NextOID: 182620
Latest checkpoint's NextMultiXactId: 1
Latest checkpoint's NextMultiOffset: 0
Latest checkpoint's oldestXID: 1741
Latest checkpoint's oldestXID's DB: 1
Latest checkpoint's oldestActiveXID: 0
Latest checkpoint's oldestMultiXid: 1
Latest checkpoint's oldestMulti's DB: 1
Latest checkpoint's oldestCommitTsXid:0
Latest checkpoint's newestCommitTsXid:0
Time of latest checkpoint: Thu 01 Oct 2020 07:15:50 PM EDT
Fake LSN counter for unlogged rels: 0/1
Minimum recovery ending location: 0/0
Min recovery ending loc's timeline: 0
Backup start location: 0/0
Backup end location: 0/0
End-of-backup record required: no
wal_level setting: hot_standby
wal_log_hints setting: off
max_connections setting: 1000
max_worker_processes setting: 8
max_prepared_xacts setting: 0
max_locks_per_xact setting: 64
track_commit_timestamp setting: off
Maximum data alignment: 8
Database block size: 8192
Blocks per segment of large relation: 8388608
WAL block size: 8192
Bytes per WAL segment: 67108864
Maximum length of identifiers: 64
Maximum columns in an index: 32
Maximum size of a TOAST chunk: 1996
Size of a large-object chunk: 2048
Date/time type storage: 64-bit integers
Float4 argument passing: by value
Float8 argument passing: by value
Data page checksum version: 0

pg_controldata output 12.3

pg_control version number: 942
Catalog version number: 201510051
Database system identifier: 6307574991682851055
Database cluster state: shut down
pg_control last modified: Thu 01 Oct 2020 07:15:50 PM EDT
Latest checkpoint location: 2FB/7C000028
Prior checkpoint location: 2FB/78000098
Latest checkpoint's REDO location: 2FB/7C000028
Latest checkpoint's REDO WAL file: 00000001000002FB0000001F
Latest checkpoint's TimeLineID: 1
Latest checkpoint's PrevTimeLineID: 1
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID: 0/130082037
Latest checkpoint's NextOID: 182620
Latest checkpoint's NextMultiXactId: 1
Latest checkpoint's NextMultiOffset: 0
Latest checkpoint's oldestXID: 1741
Latest checkpoint's oldestXID's DB: 1
Latest checkpoint's oldestActiveXID: 0
Latest checkpoint's oldestMultiXid: 1
Latest checkpoint's oldestMulti's DB: 1
Latest checkpoint's oldestCommitTsXid:0
Latest checkpoint's newestCommitTsXid:0
Time of latest checkpoint: Thu 01 Oct 2020 07:15:50 PM EDT
Fake LSN counter for unlogged rels: 0/1
Minimum recovery ending location: 0/0
Min recovery ending loc's timeline: 0
Backup start location: 0/0
Backup end location: 0/0
End-of-backup record required: no
wal_level setting: hot_standby
wal_log_hints setting: off
max_connections setting: 1000
max_worker_processes setting: 8
max_prepared_xacts setting: 0
max_locks_per_xact setting: 64
track_commit_timestamp setting: off
Maximum data alignment: 8
Database block size: 8192
Blocks per segment of large relation: 8388608
WAL block size: 8192
Bytes per WAL segment: 67108864
Maximum length of identifiers: 64
Maximum columns in an index: 32
Maximum size of a TOAST chunk: 1996
Size of a large-object chunk: 2048
Date/time type storage: 64-bit integers
Float4 argument passing: by value
Float8 argument passing: by value
Data page checksum version: 0 

And ran pg_upgrade again, and get the same error as above. What am I missing here?

• jjanes: The docs say that --segsize is specified in GB, not in blocks. When I configure and build with --with-segsize=8388608, I get a nonfunctional build.
• sharadov: I figured that, basically it's equivalent to 64 GB and re-ran, but get the same error.
• sharadov: @LaurenzAlbe - Edited the original question and pasted the output for both clusters

Answer 1

You seem to have posted the pg_controldata output for PostgreSQL 9.5 twice.

Anyway, you'll have to configure PostgreSQL v12 with a non-standard table segment size:

./configure --prefix=/opt/pgsql/PostgreSQL-12 --with-segsize=64

Also, during initdb, you will have to specify the non-standard WAL segment size:

initdb ... --wal-segsize=64 /path/to/datadir

Then pg_upgrade should succeed (if locale etc. match).

• sharadov: I double-checked, re-ran the configure and initdb with the options suggested, it still throws the same error
• Laurenz Albe: Are you using pg_upgrade from v12? Does pg_cuntroldata -D <datadir> show the same segment size for both?
• sharadov: Despite of running this ./configure --prefix=/opt/pgsql/PostgreSQL-12 --with-segsize=64, the segment size never changes. This is what I get Blocks per segment of large relation: 131072.
• Laurenz Albe: Then the problem must be that you are inadvertedly using a PostgreSQL installation different from the one you configured. Check your PATH setting or use absolute paths. Use the -D option of pg_controldata.
• sharadov: So after numerous tests, I found the issue. If I run the configure --with-segsize=64 on RHEL 6.10, the segment size will not get set to 64 GB, but if I run it on RHEL 7.8, it does. Seems like a bug.

Answer 2

So after numerous tests, I found the issue. If I run the configure --with-segsize=64 on RHEL 6.10, the segment size will not get set to 64 GB, but if I run it on RHEL 7.8, it does. Seems like a bug with RHEL 6.10.