Таким образом, в версиях 9.3 и более ранних версиях в таких случаях, как упомянуто ниже, возникала проблема:
упрощение работы с 1 ведущим и 1 ведомым, если по какой-то причине ведомое устройство очень долго не работает время в остановленном состоянии и не наступает; и если сегменты WAL первичного сервера, требуемые резервным сервером, уже были переработаны, резервный не может догнать первичный сервер, чтобы решить эту проблему, которую мы использовали, чтобы иметь нечто, называемое wal_keep_segments. Установите большее значение, и это как бы обостряет проблему.
Переход к более новым версиям postgres 9.4 и далее, мы получили replication slot.
Итак, из официальных документов:
Слоты репликации предоставляют автоматический способ гарантировать, что мастер не удаляет сегменты WAL до тех пор, пока они не будут получены всеми резервными , и что мастер не удаляет строки, которые могут вызвать восстановление конфликтуют, даже когда резервный сервер отключен.
Таким образом, в основном слоты репликации сохраняют только то количество сегментов, о котором известно, что они необходимы. Таким образом, в основном он будет функционировать так, как это было указано выше, независимо от количества строк.
Надеюсь, что это ответ на ваш вопрос, см. Официальные документы для получения дополнительной информации здесь .