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?
First make sure the file exists really in that location. Run ls $PGDATA
if there is a mistake in the environment variable you will either see the wrong files or get an error because the path does not exist.
Then make sure the owner of the parent directory /home/destination_data_directory
and all directories and files under match the user you start pg_ctl under. If they are not either use
su postgres_user
to switch to the right user before running pg_ctl or use
chown -R postgres_user /home/destination_data_directory
to change the owner of the directory and everything under it.
Best Answer
There are 3 different items in this question:
Incomplete startup packet occuring at server start is inconsequential, you may ignore it. Read Incomplete startup packet help needed (in pgsql-general mailing-list) for more.
syntax error at or near "exit" at character 1 means that a client issued
exit
as if it was an SQL statement.The could not exec error when issuing
service postgresql restart
looks like a serious installation problem but it's contradicted by the log entrydatabase system is ready to accept connections
meaning that the server started up just fine.