BUG #7683: pg_upgrade missing configuration file - Mailing list pgsql-bugs

The following bug has been logged on the website:

Bug reference:      7683
Logged by:          Bernhard Schrader
Email address:      bernhard.schrader@innogames.de
PostgreSQL version: 9.2.1
Operating system:   Debian Squeeze
Description:        =


Hi there,

short term explanation, I have the problem in Debian that I can't do a
normal pg_upgrade if I do not link /etc/postgresql/x.y/main/postgresql.conf
to /var/lib/postgresql/x.y/main/postgresql.conf, the /var/lib is the normal
datadirectory, which i add to the -d option, but debian has a seperate
configuration directory. As there are direct parameter missing for adding
this directory to the pg_upgrade command I have to link it. Also, trying to
add /etc/postgresql/x.y/main/ as data directory doesn't help, the values for
the data directory should be readable throughout the config. But if I try
it, it gives me the error message:

/usr/lib/postgresql/9.2/bin/pg_upgrade -b /usr/lib/postgresql/9.0/bin/ -B
/usr/lib/postgresql/9.2/bin/ -d /etc/postgresql/9.0/main/ -D
/etc/postgresql/9.2/main/ -p 5432 -P 5433 -v
Running in verbose mode
Finding the real data directory for the old cluster        =

/usr/lib/postgresql/9.0/bin/postmaster: invalid option -- 'C'
Try "postmaster --help" for more information.

Could not get data directory using "/usr/lib/postgresql/9.0/bin/postmaster"
-D "/etc/postgresql/9.0/main/" -C data_directory: No such file or directory
Failure, exiting

Which shouldn't be surprising because 9.0 doesn't has the -C option, but 9.2
has it. =


Here the output if i set the data directory correctly to
/var/lib/postgresql/x.y/main without link to postgresql.conf:

/usr/lib/postgresql/9.2/bin/pg_upgrade --check -b
/usr/lib/postgresql/9.0/bin/ -B /usr/lib/postgresql/9.2/bin/ -d
/var/lib/postgresql/9.0/main/ -D /var/lib/postgresql/9.2/main/ -p 5432 -P
5433 -v
Running in verbose mode
Performing Consistency Checks
-----------------------------
Checking current, bin, and data directories                 ok
Checking cluster versions                                   ok
pg_control values:

First log file ID after reset:        32
First log file segment after reset:   18
pg_control version number:            903
Catalog version number:               201008051
Database system identifier:           5570989883231871453
Latest checkpoint's TimeLineID:       3
Latest checkpoint's NextXID:          0/2415720
Latest checkpoint's NextOID:          407531
Latest checkpoint's NextMultiXactId:  188
Latest checkpoint's NextMultiOffset:  376
Latest checkpoint's oldestXID:        654
Latest checkpoint's oldestXID's DB:   1
Latest checkpoint's oldestActiveXID:  0
Maximum data alignment:               8
Database block size:                  8192
Blocks per segment of large relation: 131072
WAL block size:                       8192
Bytes per WAL segment:                16777216
Maximum length of identifiers:        64
Maximum columns in an index:          32
Maximum size of a TOAST chunk:        1996
Date/time type storage:               64-bit integers
Float4 argument passing:              by value
Float8 argument passing:              by value
pg_control values:

First log file ID after reset:        0
First log file segment after reset:   2
pg_control version number:            922
Catalog version number:               201204301
Database system identifier:           5812825747830308730
Latest checkpoint's TimeLineID:       1
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID:          0/1773
Latest checkpoint's NextOID:          12844
Latest checkpoint's NextMultiXactId:  1
Latest checkpoint's NextMultiOffset:  0
Latest checkpoint's oldestXID:        1763
Latest checkpoint's oldestXID's DB:   1
Latest checkpoint's oldestActiveXID:  0
Maximum data alignment:               8
Database block size:                  8192
Blocks per segment of large relation: 131072
WAL block size:                       8192
Bytes per WAL segment:                16777216
Maximum length of identifiers:        64
Maximum columns in an index:          32
Maximum size of a TOAST chunk:        1996
Date/time type storage:               64-bit integers
Float4 argument passing:              by value
Float8 argument passing:              by value
"/usr/lib/postgresql/9.0/bin/pg_ctl" -w -l "pg_upgrade_server.log" -D
"/var/lib/postgresql/9.0/main/" -o "-p 5432 -c autovacuum=3Doff -c
autovacuum_freeze_max_age=3D2000000000  -c listen_addresses=3D'' -c
unix_socket_permissions=3D0700" start >> "pg_upgrade_server.log" 2>&1
*failure*
There were problems executing ""/usr/lib/postgresql/9.0/bin/pg_ctl" -w -l
"pg_upgrade_server.log" -D "/var/lib/postgresql/9.0/main/" -o "-p 5432 -c
autovacuum=3Doff -c autovacuum_freeze_max_age=3D2000000000  -c
listen_addresses=3D'' -c unix_socket_permissions=3D0700" start >>
"pg_upgrade_server.log" 2>&1"
Consult the last few lines of "pg_upgrade_server.log" for
the probable cause of the failure.

connection to database failed: could not connect to server: No such file or
directory
    Is the server running locally and accepting
    connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?


could not connect to old postmaster started with the command:
"/usr/lib/postgresql/9.0/bin/pg_ctl" -w -l "pg_upgrade_server.log" -D
"/var/lib/postgresql/9.0/main/" -o "-p 5432 -c autovacuum=3Doff -c
autovacuum_freeze_max_age=3D2000000000  -c listen_addresses=3D'' -c
unix_socket_permissions=3D0700" start
Failure, exiting

To point this out, postgresql 9.0 and 9.2 are not running, if 9.0 is
running, the 9.0 tests succeed, but afaik they shouldn't running, or at
least 9.2 shouldn't running during upgrade, but without the link to the
config it will never start. The same for 9.0, if it is shut down and the
link is present, it works. I assume this is a "bug" or at least a missing
option for pg_upgrade in addition to debian. Do you confirm? Or do i
undestand something completly wrong? I hope not, thanks in advance

regards
Bernhard