Postgresql – postgres promote hot_standby (archive_command = ‘:’) to master (archive_command = ”)

A replica server (whether running as hot_standby or not) is running in what PostgreSQL calls "recovery mode". As the name suggests, this was originally developed to perform recovery from an unsafe stop: in this situation, it uses the recovery.conf file which defines how to find transaction logs (pg_xlog files) and keeps applying them until no more are available, and then exits from recovery mode into "normal" mode, and starts generating new transaction logs itself. When exiting recovery mode, the recovery.conf file is renamed to recovery.done, so that a subsequent restart goes directly to normal mode.

The changes from this process for a replication slave are:

• the transaction log data may not be coming from log files, but streamed from the master server: recovery.conf specifies which
• replicas do not exit recovery mode when no more data is available, they wait until the trigger is fired.

So due to the renaming of recovery.conf, restarting your newly-elected master preserves the property of it being a master.

However, one point to note: after recovery has completed and a server transitions from being in recovery to being in normal mode, it changes "timeline". Essentially, at this point you have forked your database: one version is the possible continuation of transaction logs from wherever they were coming from, and one version (the new version) is from the database that has just finished recovery. But you can only apply log files from a master server that is on the same timeline! This is why, after doing a failover, you need to rebuild your old master server from the new master, rather than just starting it to let it "catch up".

(This above paragraph is subject to some doubt as my experience with thee failovers is currently limited, but it's from my understanding of the documentation, and how the system works overall).

Also note that the hot_standby flag means only that a database cluster will accept connections and allow read-only queries even while it is in recovery mode: not a normal situation for a database that is recovering from a crash. Once a server is running in "normal mode", this setting is irrelevant, so it is not a problem to have it set on the old slave/new master.

It sounds like PostgreSQL is set to recover from log shipping rather than by connecting as a replication user. Please double and triple check your recovery.conf and if that doesn't work, then post it here.

The approach you are taking is a valid approach though, and it means that the recovery will just wait for the next segment until it arrives creating the message you are seeing, but it must be transferred using whatever recovery command you have configured in the master's postgresql.conf.