HAProxy is a low lewel high availability and load balancing solution. PgBouncer combines a very good connection pooler and a very limited load balancing for PostgreSQL.
So both has different goals and can not be compared like "vs" in my opinion. Though they can be used in a combination with each other, eg. if one needs to load balance read only queries between several replicas with HAProxy and these replicas are served by their own PgBouncer instances to get pooling advantages.
More about what PgBouncer is and what it is not in is perfectly described in this blog post.
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.
Best Answer
Usually the replica server is used for HA (that's why everyone is talking about promoting it) and for read scaling. From your question it seems you're interested in the later. As you use the replica for read scaling, you can use any load balancer to spread the read load between the master and slave. If the slave goes down, most load balancers will stop sending traffic to it.