

The start of log-shipping does not interfere with any query processing on the primary.The standby periodically removes old XLOG files which are no longer needed for recovery, to prevent excessive disk usage.The combination of Hot Standby and SR would make the latest data inserted into the primary visible in the standby almost immediately. XLOG records shipped are replayed as soon as possible without waiting until XLOG file has been filled.The standby continuously replays XLOG records shipped without using pg_standby.The maximum number of standbys can be specified as a GUC variable.The delay/death of a standby does not harm log-shipping to other standbys. XLOG records are concurrently shipped to all these standbys. More than one standby can establish a connection to the primary for SR.XLOG files shipped can be used for a normal recovery and PITR. The content of XLOG files written to the standby are exactly the same as those on the primary.This means the window for data loss in SR is usually smaller than in warm standby, unless the warm standby was also configured for record-based shipping (which is complicated to setup). In SR, XLOG records in partially-filled XLOG file are shipped too, implementing record-based log-shipping. In the existing warm standby, only records in a filled file are shipped, what's referred to as file-based log-shipping.XLOG records generated in the primary are periodically shipped to the standby via the network.Synchronous Log Shipping Replication Presentation introduces the early design of the feature. SR was developed for inclusion in PostgreSQL 9.0 by NTT OSS Center.

1 Developer and historical details on the projectĭeveloper and historical details on the project.
