The role used for the replication connection must have the <literal>REPLICATION</literal> attribute (or be a superuser). If the role lacks <literal>SUPERUSER</literal> and <literal>BYPASSRLS</literal>, publisher row security policies can execute. If the role does not trust all table owners, include <literal>options=-crow_security=off</literal> in the connection string; if a table owner then adds a row security policy, that setting will cause replication to halt rather than execute the policy. Access for the role must be configured in <filename>pg_hba.conf</filename> and it must have the <literal>LOGIN</literal> attribute. レプリケーション接続のために使われるロールには、REPLICATION属性が付与されている（もしくはスーパーユーザである）必要があります。 ロールに SUPERUSERとBYPASSRLSがない場合は、パブリッシャーは行セキュリティポリシーを実行できます。 ロールが全てのテーブルの所有者を信頼していない場合、接続文字列にoptions=-crow_security=offを含めてください。 テーブルの所有者が行セキュリティポリシーを追加した場合、ポリシーが実行されるのではなく、レプリケーションが停止します。 接続のためのロールはpg_hba.confで設定され、 LOGIN属性を持つ必要があります。

In order to be able to copy the initial table data, the role used for the replication connection must have the <literal>SELECT</literal> privilege on a published table (or be a superuser). テーブルの初期データをコピーできるためには、レプリケーション接続に使用されるロールは、パブリッシュされるテーブルに対してSELECT権限を持っていなければなりません。 （あるいはスーパーユーザでなければなりません。）

To create a publication, the user must have the <literal>CREATE</literal> privilege in the database. パブリケーションを作成するためには、ユーザはデータベース中のCREATE権限を持っていなければなりません。

To add tables to a publication, the user must have ownership rights on the table. To add all tables in schema to a publication, the user must be a superuser. To create a publication that publishes all tables or all tables in schema automatically, the user must be a superuser. テーブルをパブリケーションに追加するためには、ユーザはテーブルの所有権限を持っていなければなりません。 スキーマのすべてのテーブルをパブリケーションに追加するには、ユーザがスーパーユーザである必要があります。 自動的にすべてのテーブルにパブリッシュするパブリケーションを作成するには、ユーザはスーパーユーザでなければなりません。

There are currently no privileges on publications. Any subscription (that is able to connect) can access any publication. Thus, if you intend to hide some information from particular subscribers, such as by using row filters or column lists, or by not adding the whole table to the publication, be aware that other publications in the same database could expose the same information. Publication privileges might be added to <productname>PostgreSQL</productname> in the future to allow for finer-grained access control. 現在、パブリケーションに権限はありません。 （接続可能な）サブスクリプションはすべて、パブリケーションにアクセスできます。 そのため、行フィルタや列リストを使用したり、テーブル全体をパブリケーションに追加しないなどして、特定のサブスクライバからの情報を隠したい場合は、同じデータベース内の他のパブリケーションが同じ情報にアクセスできる可能性があることに注意してください。 より細かいアクセス制御を可能にするために、パブリケーション権限が将来PostgreSQLに追加される可能性があります。

To create a subscription, the user must have the privileges of the <literal>pg_create_subscription</literal> role, as well as <literal>CREATE</literal> privileges on the database. 《機械翻訳》サブスクリプションを作成するには、ユーザはpg_create_subscriptionロールの権限とデータベースに対するCREATE権限を持っている必要があります。

The subscription apply process will, at a session level, run with the privileges of the subscription owner. However, when performing an insert, update, delete, or truncate operation on a particular table, it will switch roles to the table owner and perform the operation with the table owner's privileges. This means that the subscription owner needs to be able to <literal>SET ROLE</literal> to each role that owns a replicated table. サブスクリプション適用プロセスは、セッションレベルで、サブスクリプション所有者の権限で実行されます。 ただし、特定のテーブルに対して挿入、更新、削除または切捨て操作を実行すると、テーブルの所有者にロールを切り替え、テーブルの所有者の権限で操作が実行されます。 つまり、サブスクリプション所有者は、レプリケートされたテーブルを所有する各ロールに対してSET ROLEを実行できる必要があります。

If the subscription has been configured with <literal>run_as_owner = true</literal>, then no user switching will occur. Instead, all operations will be performed with the permissions of the subscription owner. In this case, the subscription owner only needs privileges to <literal>SELECT</literal>, <literal>INSERT</literal>, <literal>UPDATE</literal>, and <literal>DELETE</literal> from the target table, and does not need privileges to <literal>SET ROLE</literal> to the table owner. However, this also means that any user who owns a table into which replication is happening can execute arbitrary code with the privileges of the subscription owner. For example, they could do this by simply attaching a trigger to one of the tables which they own. Because it is usually undesirable to allow one role to freely assume the privileges of another, this option should be avoided unless user security within the database is of no concern. サブスクリプションが run_as_owner = trueで構成されている場合、ユーザの切り替えは発生しません。 その代わり、すべての操作は、サブスクリプションの所有者の権限で実行されます。 この場合、サブスクリプションの所有者は、対象テーブルからのSELECT、INSERT、UPDATE、およびDELETE権限のみが必要であり、テーブル所有者に対するSET ROLE権限は不要です。 しかし、これはまた、レプリケーションが行われているテーブルを所有するユーザは、サブスクリプション所有者の権限で任意のコードを実行できることを意味します。 たとえば、所有するテーブルにトリガーを付加するだけで、これを実行できます。 通常、あるロールが別のロールの権限を自由に引き受けることは望ましくないので、データベース内のユーザセキュリティが問題にならない場合以外は、このオプションを避けるべきです。

On the publisher, privileges are only checked once at the start of a replication connection and are not re-checked as each change record is read. パブリッシャーでは、権限はレプリケーション接続の開始時に一度だけチェックされ、変更レコードが読み取られるたびに再チェックされません。

On the subscriber, the subscription owner's privileges are re-checked for each transaction when applied. If a worker is in the process of applying a transaction when the ownership of the subscription is changed by a concurrent transaction, the application of the current transaction will continue under the old owner's privileges. サブスクライバーでは、サブスクリプション所有者の権限は、適用時にトランザクションごとに再チェックされます。 同時に並行しているトランザクションによってサブスクリプションの所有権が変更されたときにワーカーがトランザクションを適用している場合、現在のトランザクションの適用は古い所有者の権限で継続されます。