There is another physical replication scenario that can work on top of log shipping or without log shipping at all. It is streaming replication. Streaming replications implies a connection between the standby and the master servers and the master would send all the transaction log entries directly to the standby. By doing this the standby will have all the recent changes without waiting for the WAL files to be archived.

To set up streaming replication, in addition to the steps mentioned previously the following should be done on the master:

• A database role for replication should be created in the database, for example, like this:

postgres=# CREATE USER streamer REPLICATION;
CREATE USER

• Connections for this user should be allowed in the file pg_hba.conf to the virtual database called replication, for example, like this:

host    replication    streamer    172.16.0.2/32   md5

And the following actions should be taken on the standby server:

• Add the parameter primary_conninfo to the file recovery.conf that would set up the connection from the standby to the master, for example, as follows:

primary_conninfo = 'host=172.16.0.1 port=5432 user=streamer password=secret'

This is already enough. If the WAL archive was enabled and configured, then the log shipping scenario will be performed first until all the WAL files from the archive are applied to the backup database. When there are no more files, the standby server will connect to the master server and start receiving new WAL entries directly from the master. If that connection breaks or if the standby is restarted, the process will start again.

It is possible to set up streaming replication without the WAL archive at all. The master server by default stores last 64 WAL files in the folder pg_wal. It can send them to the standby when necessary. The size of each file is 16 MB. That means, as long as the amount of changes in the data files is less then 1 GB, the streaming replication is able to replay these changes in the backup database without using the WAL archive. 

Additionally, PostgreSQL provides a way to make the master server aware of which WAL files were processed by the standby and which were not. In case the standby is slow (or simply disconnected), the master would not delete the files that are not yet processed even if the number of them is more than 64. This is done by creating a replication slot on the master. Then the standby will use the replication slot and the master will keep track of which of the WAL files were processed for this replication slot.

To use this feature, make the following on the master:

• Create the replication slot on the master by executing the function pg_create_physical_replication_slot() in the database:

postgres=# SELECT * FROM pg_create_physical_replication_slot('slot1');
 slot_name | lsn 
-----------+-----
 slot1     | 
(1 row)

• Make sure the configuration parameter max_replication_slots in the file postgresql.conf is big enough

And make the following on the standby server:

• Add the parameter primary_slot_nameto the file recovery.conf:

primary_slot_name = 'slot1'

After this, the master will not delete the WAL files that are not received by the standby even if the standby is not connected. When the standby connects again, it will receive all the missing WAL entries and the master will delete the old files then.

The benefits of streaming replication over log shipping are as follows:

• The lag between the backup and the master is smaller because the WAL entries are sent immediately after the transactions are finished on the master, without waiting for the WAL files to be archived
• It is possible to set up the replication without WAL archiving at all, therefore no need to set up a network storage or another common location for the master and the standby