Логическое декодирование — это процедура извлечения всех постоянных изменений, происходящих в таблицах базы данных, в согласованном и понятном формате, который можно интерпретировать, не имея полного представления о внутреннем состоянии базы данных.

В Postgres Pro логическое декодирование реализуется путём перевода содержимого журнала предзаписи, описывающего изменения на уровне хранения, в специальную форму уровня приложения, например, в поток кортежей или операторов SQL.

В контексте логической репликации слот представляет поток изменений, которые могут быть воспроизведены клиентом в том порядке, в каком они происходили на исходном сервере. Через каждый слот передаётся последовательность изменений в одной базе данных.

Слоту репликации назначается идентификатор, уникальный для всех баз данных в кластере Postgres Pro. Слоты сохраняются независимо от подключений, использующих их, и защищены от сбоев сервера.

При обычных условиях через логический слот каждое изменение передаётся только один раз. Текущая позиция в каждом слоте сохраняется только в контрольной точке, так что в случае сбоя слот может вернуться к предыдущему LSN, вследствие чего последние изменения могут быть переданы повторно при перезапуске сервера. За исключение нежелательных эффектов от повторной обработки одного и того же сообщения отвечают клиенты логического декодирования. Клиенты могут запоминать при декодировании, какой последний LSN они уже получали, и пропускать повторяющиеся данные или (при использовании протокола репликации) запрашивать, чтобы декодирование начиналось с этого LSN, а не с позиции, выбираемой сервером. Для этого разработан механизм отслеживания репликации, о котором можно узнать подробнее в описании источников репликации.

Для одной базы данных могут существовать несколько независимых слотов. Каждый слот имеет собственное состояние, что позволяет различным потребителям получать изменения с разных позиций в потоке изменений базы данных. Для большинства приложений каждому потребителю требуется отдельный слот.

Слот логической репликации ничего не знает о состоянии получателя(ей). Возможно даже иметь несколько различных потребителей одного слота в разные моменты времени; они просто будут получать изменения с момента, когда их перестал получать предыдущий потребитель. Но в любой определённый момент получать изменения может только один потребитель.

Логический слот репликации также можно создать на сервере горячего резерва. Чтобы запретить VACUUM удалять требуемые строки из системных каталогов, на резервном сервере необходимо установить параметр hot_standby_feedback. Несмотря на это, если какие-либо требуемые строки будут удалены, слот станет аннулирован. Настоятельно рекомендуется использовать физический слот между ведущим и резервным сервером. В противном случае hot_standby_feedback будет работать только пока соединение активно (например, перезапуск узла может разорвать соединение). Затем ведущий сервер может удалить строки системного каталога, которые могут потребоваться для логического декодирования на резервном сервере (поскольку ведущий сервер не знает о catalog_xmin на резервном сервере). Существующие логические слоты в режиме ожидания также становятся недействительными, если значение wal_level на основном сервере становится ниже logical. Это происходит, как только резервный сервер обнаруживает такое изменение в потоке WAL и означает, что для отстающих процессов walsender (если таковые имеются) некоторые записи WAL до изменения параметра wal_level на ведущем сервере не будут декодированы.

Для создания логического слота необходима информация обо всех текущих транзакциях. На ведущем сервере эта информация доступна напрямую, а на резервном её необходимо получать от ведущего. Таким образом, при создании слота может потребоваться ожидание каких-либо действий на ведущем сервере. Если ведущий сервер простаивает, создание логического слота на резервном может занять много времени. Это время можно сократить, вызвав функцию pg_log_standby_snapshot на ведущем сервере.

Модули вывода переводят данные из внутреннего представления в журнале предзаписи в формат, устраивающий потребителя слота репликации.

Когда новый слот репликации создаётся через интерфейс потоковой репликации, экспортируется снимок (см. CREATE_REPLICATION_SLOT), который будет показывать ровно то состояние базы данных, изменения после которого будут включаться в поток изменений. Используя его, можно создать новую реплику, воспользовавшись командой SET TRANSACTION SNAPSHOT, чтобы получить состояние базы в момент создания слота. После этого данную транзакцию можно использовать для выгрузки состояния базы на момент экспорта снимка, а затем изменять это состояние, применяя содержимое слота, так что никакие изменения не будут потеряны.

Создание снимка возможно не всегда. В частности, невозможно создать снимок при подключении к горячему резерву. Приложения, которым не требуется экспорт снимка, могут подавить его, воспользовавшись указанием NOEXPORT_SNAPSHOT.