Running pg_dump on a hot standby server?

AFAIK, running pg_dump on a hot standby is one of the major things standbys are useful for. It's perfectly safe, though it isn't perfectly reliable - the dumps can fail if the standby aborts the transaction when it's falling too far behind the master.

The only thing you really need to watch is to make sure the standby is current and is keeping up. If the standby lost its connection to master and fell too far behind, you don't want to be merrily backing up a three week out-of-date standby.

You will need to allow the standby to fall quite far behind the master during the backup, since it'll otherwise have to cancel your pg_dump transaction in order to continue replaying WAL. See the documentation on hot standby, particularly the "handling query conflicts" section, and the max_standby_archive_delay and max_standby_streaming_delay parameters.

Note that the master must be willing to keep enough WAL archives to allow the slave to catch up again.

1. We do backup on standby, it is perfectly fine.
2. To avoid cancelled statement conflict during backup on standby system, you need to pause replication on standby using SELECT pg_xlog_replay_pause();, then run your backup, once it is finished run SELECT pg_xlog_replay_resume(); to resume replication. Keep in mind that running above commands will cause recovery lag on the slave, which might be quite large, depending on you database size. Also, take into account the space WAL segments will take, as they will not be replayed on slave during the pause.

You may find some other useful administractive functions in documentation. For instance, check if the server is actually in recovery, prior to pausing it: SELECT pg_is_in_recovery().