WAL

TBD: diagram 1. Create replication slot This way, you preserve WAL (new changes) from being deleted. This would also create a snapshot of a current state. Snapshot can be exported, or reused in current transaction. 2. Import existing data. In replication only changes are streamed. Current state needs to be backuped manually. Physical replication: There is a mechanism to make a backup of a running server, called “base backup”. You need to specify snapshot name, to avoid data races. Base backup is tar archive of current pg_data folder, that can be used as replica initial data. ...

Write-Ahead Log docs As it states in name, it’s log that’s written BEFORE any actual changes are made. The most important thing, WAL can be replayed and will always give same result. Being compact binary representation of operations and minimal data used in them, gives us few functions: Ability to restore after crash Replicate data by transfering log segments and replaying them in replica nodes. Replacing multiple random writes with single sequential write. It can however use all of your disk space, quite fast. Serialized transactions use way more disk space then result of execution. So log files, which were applied and fsync-ed to disk, are beeing garbage collected asap. ...

The power of sequential WAL decoding.