When trigger replication is preferable to PostgreSQL built-in

Since PostgreSQL version 9.0, there is a built-in Master-Slave replication mechanism (streaming replication).
However, with its appearance, old trigger mechanisms should not be thrown away.

In general, if we need something more than one absolutely exact copy of the entire DB server, then the triggers remain with us.

Examples of such situations:

• If failover is required (i.e., the Master stops and all requests temporarily go to the Slave, and then the launched Master starts catching up to the current state from the Slave).
• Master and Slave are not 1: 1 identical. For example, for some reason, additional data (databases / tables) must be kept on the Slave, or not all bases / tables are subject to copying from the Master, or when deleting data, they must be saved on the Slave.
• The project has to use the food "zoo" - that is, Master and Slave have for some reason different versions, or the versions are the same, but the OS has a different “bit depth”.
• The project requires recursive replication of Master-Slave1-Slave2-Slave3 or in a really loaded INSERT / UPDATE project more than 1 Slave is connected to the Master in parallel (although some projects have a load that can work normally and up to 5-6 Slave).
• If for some reason you need different access rights to the database objects on the Master and Slave.

')
Add additional options in the comments.

Note: The ability to build a failover is declared a month ago in version 9.1 called "Synchronous Replication". However, I personally have not yet conducted experiments.