Роль, используемая для соединения для репликации, должна иметь REPLICATION атрибут (или быть суперпользователем). Если у роли отсутствует SUPERUSER и BYPASSRLS, могут применяться политики защиты строк издателя. Если роль не является доверенной для всех владельцев таблиц, необходимо включить options=-crow_security=off в строку подключения; если владелец таблицы добавит политику защиты строк, данный параметр приведет к остановке репликации вместо выполнения политики. Доступ для роли должен быть настроен в pg_hba.conf и она должна иметь LOGIN атрибут.

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

Для создания публикации пользователь должен иметь привилегию CREATE в базе данных.

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

В настоящее время права доступа для публикаций не предусмотрены. Любая подписка (имеющая возможность подключения) может получить доступ к любой публикации. Таким образом, если планируется скрыть определенную информацию от конкретных подписчиков (например, с помощью фильтров строк или списков столбцов, или путем добавления таблицы в публикацию не полностью), следует учитывать, что другие публикации в той же базе данных могут открыть доступ к этой же информации. В будущем могут быть добавлены привилегии для публикаций Digital Q.DataBase для обеспечения более гибкого управления доступом.

Для создания подписки пользователь должен обладать правами роли pg_create_subscription , а также CREATE привилегиями в базе данных.

Процесс применения подписки на уровне сеанса запускается с привилегиями владельца подписки. Однако при выполнении операций вставки, обновления, удаления или очистки (truncate) в конкретной таблице будет осуществляться переключение на роль владельца таблицы с выполнением операций от имени этой роли. Это означает, что владелец подписки должен иметь возможность выполнять команду SET ROLE для каждой роли, которая является владельцем реплицируемой таблицы.

Если подписка настроена с параметром run_as_owner = true, переключение пользователей не выполняется. Вместо этого все операции будут выполняться с правами владельца подписки. В этом случае владельцу подписки требуются только привилегии для SELECT, INSERT, UPDATE, и DELETE из целевой таблицы и не требует наличия привилегий для SET ROLE владельцу таблицы. Однако это также означает, что любой пользователь, являющийся владельцем таблицы, в которую выполняется репликация, может выполнять произвольный код с привилегиями владельца подписки. Например, это можно сделать путем простого назначения триггера для одной из принадлежащих пользователю таблиц. Поскольку предоставление одной роли возможности беспрепятственно использовать привилегии другой роли обычно нежелательно, этого варианта следует избегать, за исключением случаев, когда безопасность пользователей внутри базы данных не имеет значения.

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

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