Postgres Upgrade Issues with pg_upgrade

All we need is an easy explanation of the problem, so here it is.

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?

How to solve :

I know you bored from this bug, So we are here to help you! Take a deep breath and look at the explanation of your problem. We have many solutions to this problem, But we recommend you to use the first method because it is tested & true method that will 100% work for you.

Method 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).

Method 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.

Note: Use and implement method 1 because this method fully tested our system.
Thank you 🙂

Leave a Reply