Description of problem: pg_upgrade from rh-postgresql95 fails against el7 postgresql (9.2) with command: "/usr/bin/pg_ctl" -w -l "pg_upgrade_server.log" -D "/var/lib/pgsql/data" -o "-p 50432 -b -c listen_addresses='' -c unix_socket_permissions=0700 -c unix_socket_directory='/tmp'" start >> "pg_upgrade_server.log" 2>&1 waiting for server to start....FATAL: unrecognized configuration parameter "unix_socket_directory" .... stopped waiting pg_ctl: could not start server The root cause is that the configuration parameter unix_socket_directory has been replaced by unix_socket_directories (plural!!!) with upstream postgres 9.3 (see: https://www.postgresql.org/docs/current/static/release-9-3.html#AEN114343 ) But Fedora maintainers backported that change to 9.1 and 9.2, see: https://bugzilla.redhat.com/show_bug.cgi?id=853353 https://bugzilla.redhat.com/show_bug.cgi?id=825448 Now pg_upgrade checks the source PostgreSQL version in order to get the right list of options for it. It uses unix_socket_directory if source is < 9.3, unix_socket_directories otherwise. See https://github.com/postgres/postgres/blob/837255cc81fb59b12f5a70ac2a8a9850bccf13e0/src/bin/pg_upgrade/server.c#L213 The problem is that now, due to the back-porting of that change at F17 time, pc_ctl on postgresql 9.2 shipped with el7 expects unix_socket_directories as it's 9.3 and so it fails when run by pg_upgrade (which ignores the back-port of the 9.3 parameter at F17 time). Version-Release number of selected component (if applicable): rh-postgresql95.x86_64 2.2-2.el7 How reproducible: 100% Steps to Reproduce: 1. run pg_upgrade 2. 3. Actual results: command: "/usr/bin/pg_ctl" -w -l "pg_upgrade_server.log" -D "/var/lib/pgsql/data" -o "-p 50432 -b -c listen_addresses='' -c unix_socket_permissions=0700 -c unix_socket_directory='/tmp'" start >> "pg_upgrade_server.log" 2>&1 waiting for server to start....FATAL: unrecognized configuration parameter "unix_socket_directory" .... stopped waiting pg_ctl: could not start server Expected results: It successfully executes Additional info: Maybe it's worth to be fixed in Fedora PostgreSQL [root@centos73e ~]# postgres --version postgres (PostgreSQL) 9.2.18 [root@centos73e ~]# postgres --describe-config | grep -o 'unix_socket_director\w*' unix_socket_directories [root@centos73e ~]# yum list installed | grep postgresql-server postgresql-server.x86_64 9.2.18-1.el7 @base rh-postgresql95-postgresql-server.x86_64
(In reply to Simone Tiraboschi from comment #0) > The problem is that now, due to the back-porting of that change at F17 time, > pc_ctl on postgresql 9.2 shipped with el7 expects unix_socket_directories as > it's 9.3 and so it fails when run by pg_upgrade (which ignores the back-port > of the 9.3 parameter at F17 time). That's known problem; but since RHEL7 PostgreSQL 9.2 behaves differently from upstream postgresql, pg_upgrade from rhscl doesn't know whether it is performing upgrade *from* data generated by upstream postgresql server or *from* datadir generated by RHEL7 "downstream patched" server. That's why there's (temporary, for RHEL7 time-being) environment variable REDHAT_PGUPGRADE_FROM_RHEL. Set that variable to '1' and pg_upgrade should behave correctly (ie. it should use unix_socket_directories even for 9.2 server). Other option (and it is preferred!) is to (a) backup first and (b) use the 'postgresql-setup --upgrade' command wrapper (instead of using pg_upgrade directly). This way you save a lot of headaches with permissions, enabling collections, environment variables, etc.