Do I need to perform any tasks after Postgres goes into recovery mode? For starters, I do not have any sort of automated failover in place.

After two scenarios, I'm unsure of the state of the database and any required actions, if any, to take:


My master server disappears off the face of the planet and I touch my_trigger_file, converting my standby into a master server.
My master server crashes, then restarts in recovery mode


My assumption is that the server in question in each of those scenarios will first be in recovery mode, will then finish recovering, and will finally be ready as a master server.

In scenario 2 my assumption means things are back to normal, while in scenario 1 my assumption means the standby has no idea it was ever a standby and is now simply a master.

Are these assumptions correct, or are there other actions that need to take place in either or both scenarios after recovery finishes (aside from creating a new slave in the case of scenario 1)?

Also, is there a notable technical difference between the state of a slave server after becoming a master vs a master server undergoing recovery after a crash, or as far as Postgres is concerned, are they both essentially master servers that just recovered from something?

I'm using Postgres 9.2 with asynchronous streaming replication.
May I suggest upgrading to PostgreSQL 9.3 (freshly out!)? Some write that the new Streaming-Only Remastering capability turns a replica in a set of replicas into the new master for all of the other replicas. Apparently, it's even more useful in combination with the cascading replication you are using in 9.2 

In PostgreSQL 9.2, cascading replication really requires file-based WAL archiving to work in case of disaster recovery. PostgreSQL 9.3 will not require that: you can set up large replication clusters of whatever length you want without any WAL archiving.

More information:


What's new in PostgreSQL 9.3
Cascading Replication and Cycles