The message "The database system is starting up." does not indicate an error. The reason it is at the FATAL level is so that it will always make it to the log, regardless of the setting of log_min_messages
:
http://www.postgresql.org/docs/9.1/interactive/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHEN
After the rsync, did you really run what you show?:
pgsql -c "select pg_stop_backup();";
Since there is, so far as I know, no pgsql
executable, that would leave the backup uncompleted, and the slave would never come out of recovery mode. On the other hand, maybe you really did run psql
, because otherwise I don't see how the slave would have logged such success messages as:
Log: consistent recovery state reached at 0/BF0000B0
and:
Log: streaming replication successfully connected to primary
Did you try connecting to the slave at this point? What happened?
The "Success. You can now start..." message you mention is generated by initdb
, which shouldn't be run as part of setting up a slave; so I think you may be confused about something there. I'm also concerned about these apparently conflicting statements:
The only ways I have restarted Postgres is through the service
postgresql-9.1 restart or /etc/init.d/postgresql-9.1 restart commands.
After I receive this error, I kill all processes and again try to
restart the database...
Did you try to stop the service through the service script? What happened? It might help in understanding the logs if you prefixed lines with more information. We use:
log_line_prefix = '[%m] %p %q<%u %d %r> '
The recovery.conf
script looks odd. Are you copying from the master's pg_xlog directory, the slave's active pg_xlog directory, or an archive directory?
I use the source version and have never had any problems - here is the short version of the install for the source distribution.
Short Version
./configure
make
su
make install
adduser postgres
mkdir /usr/local/pgsql/data
chown postgres /usr/local/pgsql/data
su - postgres
/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data >logfile 2>&1 &
/usr/local/pgsql/bin/createdb test
/usr/local/pgsql/bin/psql test
initdb
initialises the server instance after install (an install from an rpm or apt-get may take care of this for you).
postgres -D /usr/local/pgsql/data > logfile 2>&1 &
or
./bin/pg_ctl -D ./data/ -l logfile start
Should start the server for you - I generally use the pg_ctl
option.
(When you run initdb
, you should see the above commands as a hint as to how to start the server - but, again, you may not have to run initdb
).
Then you can use createdb
test to create your first database.
If I were you, I'd start by executing
$export PATH=/usr/lib/postgresql/9.3/bin:$PATH
(or even better, put it in your .bashrc).
Then try running
pg_ctl -D /var/lib/postgresql/9.3/main/ -l logfile start
and then
createdb my_test - it will be in the ...9.3/main directory.
Notice, there are no quotes around -D or the data path.
Running pg_ctl --help
gives
-c, --core-files allow postgres to produce core files
I think that PostgreSQL should pick up your postgresql.conf without the need to use -c - I'm not even sure that it's a correct option.
Then run psql test
and you should be connected to your test database.
Best Answer
I hacked the problem by running (as root):
Run
pg_upgrade
as intended, then undo the hack:The problem is that pg_upgrade executes the program pg_ctrl with arguments that specify files in the old "unix_socket_directory" rather than the new "unix_socket_directories" (note the second is plural). This hack renames the original
/usr/bin/pg_ctl
to/usr/bin/pg_ctl-orig
, and then creates a shell script in its place that simply calls the original pg_ctl program, passing all arguments with any strings "unix_socket_directory" changed to "unix_socket_directories".In bash, one can change a portion of a string, say from
bar
tobaz
in a variable$foo
, by using${foo/bar/baz}
(note this does not change the variable, but rather returns the variable's modified contents). Arrays can also be used with${x/y/z}
to retrieve an array with all of its contents replaced, all at once. The variable$@
is an array that contains all arguments passed to the program/script/function, so the new pg_ctl script executes the old one with all arguments changed from the old directory name to the new one.