When using replication slots with standby nodes, a master node retains the necessary WAL files in pg_xlog until the standby has received them at the cost of monitoring the space used by WAL files in pg_xlog as now the disk space that those filesuse is not strictly controlled by wal_keep_segments or checkpoint_segments but by elements (perhaps) external to the server where the master node is running.
In the case of a standby node using streaming replication, the server does not actually wait for the slave to catch up if it disconnects and simply deletes the WAL files that are not needed. This has the advantage to facilitate management of the disk space used by WAL files: use checkpoint_segments as well in this case. The amount of WAL to keep on master side can as well be tuned with wal_keep_segments.
On Wed, Feb 27, 2019 at 6:10 PM John Scalia <jayknowsunix@xxxxxxxxx> wrote:
Hello, folks,
Yesterday, I had a small file system fill up, due to some logical replication testing we had been performing. We had been testing IBM’s IIDR system and apparently it had built a logical replication slot on my server. When the test was completed, nobody removed the slot, so WAL segments stopped being dropped. Now I can understand the difficulty separating what physical versus logical replication needs from the WAL segments, but as logical replication is database specific not cluster wide, this behavior was a little unexpected, since the WAL segments are cluster wide. Are WAL segments going to pile up whenever something drops a logical replication connection? I’ve seen it, but it seems like this could be a bad thing.
-
Jay
Sent from my iPhone
