As mentioned earlier, each (active) subscription receives changes from a replication slot on the remote (publishing) side. 前述のように、各々の（有効な）サブスクリプションは、リモート（パブリッシュしている）側のレプリケーションスロットに対する変更を受信します。

Additional table synchronization slots are normally transient, created internally to perform initial table synchronization and dropped automatically when they are no longer needed. These table synchronization slots have generated names: <quote><literal>pg_%u_sync_%u_%llu</literal></quote> (parameters: Subscription <parameter>oid</parameter>, Table <parameter>relid</parameter>, system identifier <parameter>sysid</parameter>) 追加的なテーブル同期スロットは通常一時的なもので、初期テーブル同期を実行するために内部的に作成され、不要になった時に自動的に削除されます。 これらのテーブル同期スロットには「pg_%u_sync_%u_%llu」（パラメータは、サブスクリプションoid、テーブルrelid、システム識別子sysid）という名前が生成されます。

Normally, the remote replication slot is created automatically when the subscription is created using <command>CREATE SUBSCRIPTION</command> and it is dropped automatically when the subscription is dropped using <command>DROP SUBSCRIPTION</command>. In some situations, however, it can be useful or necessary to manipulate the subscription and the underlying replication slot separately. Here are some scenarios: 通常、リモートのレプリケーションスロットはCREATE SUBSCRIPTIONでサブスクリプションが作成されるときに自動的に作成され、サブスクリプションがDROP SUBSCRIPTIONで削除されるときに自動的に削除されます。 しかしながら、状況によっては、サブスクリプションとその下にあるレプリケーションスロットを別々に操作することが有用であったり必要であったりします。 以下にいくつかシナリオを示します。

Create some test tables on the publisher. パブリッシャーでいくつかテストテーブルを作成します。

test_pub=# CREATE TABLE t1(a int, b text, PRIMARY KEY(a));
CREATE TABLE
test_pub=# CREATE TABLE t2(c int, d text, PRIMARY KEY(c));
CREATE TABLE
test_pub=# CREATE TABLE t3(e int, f text, PRIMARY KEY(e));
CREATE TABLE

Create the same tables on the subscriber. サブスクライバーに同じテーブルを作成します。

test_sub=# CREATE TABLE t1(a int, b text, PRIMARY KEY(a));
CREATE TABLE
test_sub=# CREATE TABLE t2(c int, d text, PRIMARY KEY(c));
CREATE TABLE
test_sub=# CREATE TABLE t3(e int, f text, PRIMARY KEY(e));
CREATE TABLE

Insert data to the tables at the publisher side. パブリッシャー側のテーブルにデータを挿入します。

test_pub=# INSERT INTO t1 VALUES (1, 'one'), (2, 'two'), (3, 'three');
INSERT 0 3
test_pub=# INSERT INTO t2 VALUES (1, 'A'), (2, 'B'), (3, 'C');
INSERT 0 3
test_pub=# INSERT INTO t3 VALUES (1, 'i'), (2, 'ii'), (3, 'iii');
INSERT 0 3

Create publications for the tables. The publications <literal>pub2</literal> and <literal>pub3a</literal> disallow some <link linkend="sql-createpublication-with-publish"><literal>publish</literal></link> operations. The publication <literal>pub3b</literal> has a row filter (see <xref linkend="logical-replication-row-filter"/>). 《機械翻訳》テーブルのパブリケーションを作成します。 パブリケーション pub2とpub3aはpublish操作を許可しません。 パブリケーションpub3bは、行フィルタを持っています（31.3を参照）。

test_pub=# CREATE PUBLICATION pub1 FOR TABLE t1;
CREATE PUBLICATION
test_pub=# CREATE PUBLICATION pub2 FOR TABLE t2 WITH (publish = 'truncate');
CREATE PUBLICATION
test_pub=# CREATE PUBLICATION pub3a FOR TABLE t3 WITH (publish = 'truncate');
CREATE PUBLICATION
test_pub=# CREATE PUBLICATION pub3b FOR TABLE t3 WHERE (e > 5);
CREATE PUBLICATION

Create subscriptions for the publications. The subscription <literal>sub3</literal> subscribes to both <literal>pub3a</literal> and <literal>pub3b</literal>. All subscriptions will copy initial data by default. パブリケーションのサブスクリプションを作成します。 サブスクリプションsub3は、pub3aとpub3bの両方をサブスクライブします。 デフォルトでは、すべてのサブスクリプションによって初期データがコピーされます。

test_sub=# CREATE SUBSCRIPTION sub1
test_sub-# CONNECTION 'host=localhost dbname=test_pub application_name=sub1'
test_sub-# PUBLICATION pub1;
CREATE SUBSCRIPTION
test_sub=# CREATE SUBSCRIPTION sub2
test_sub-# CONNECTION 'host=localhost dbname=test_pub application_name=sub2'
test_sub-# PUBLICATION pub2;
CREATE SUBSCRIPTION
test_sub=# CREATE SUBSCRIPTION sub3
test_sub-# CONNECTION 'host=localhost dbname=test_pub application_name=sub3'
test_sub-# PUBLICATION pub3a, pub3b;
CREATE SUBSCRIPTION

Observe that initial table data is copied, regardless of the <literal>publish</literal> operation of the publication. パブリケーションのパブリッシュ操作に関係なく、初期テーブルデータがコピーされることに注意してください。

test_sub=# SELECT * FROM t1;
 a |   b
---+-------
 1 | one
 2 | two
 3 | three
(3 rows)

test_sub=# SELECT * FROM t2;
 c | d
---+---
 1 | A
 2 | B
 3 | C
(3 rows)

Furthermore, because the initial data copy ignores the <literal>publish</literal> operation, and because publication <literal>pub3a</literal> has no row filter, it means the copied table <literal>t3</literal> contains all rows even when they do not match the row filter of publication <literal>pub3b</literal>. さらに、最初のデータコピーではパブリッシュ操作が無視され、パブリケーションpub3aには行フィルタがないため、コピーされたテーブルt3には、パブリケーションpub3bの行フィルタに一致しない場合でもすべての行が含まれていることになります。

test_sub=# SELECT * FROM t3;
 e |  f
---+-----
 1 | i
 2 | ii
 3 | iii
(3 rows)

Insert more data to the tables at the publisher side. パブリッシャー側のテーブルにさらにデータを挿入します。

test_pub=# INSERT INTO t1 VALUES (4, 'four'), (5, 'five'), (6, 'six');
INSERT 0 3
test_pub=# INSERT INTO t2 VALUES (4, 'D'), (5, 'E'), (6, 'F');
INSERT 0 3
test_pub=# INSERT INTO t3 VALUES (4, 'iv'), (5, 'v'), (6, 'vi');
INSERT 0 3

Now the publisher side data looks like: パブリッシャー側のデータは次のようになります。

test_pub=# SELECT * FROM t1;
 a |   b
---+-------
 1 | one
 2 | two
 3 | three
 4 | four
 5 | five
 6 | six
(6 rows)

test_pub=# SELECT * FROM t2;
 c | d
---+---
 1 | A
 2 | B
 3 | C
 4 | D
 5 | E
 6 | F
(6 rows)

test_pub=# SELECT * FROM t3;
 e |  f
---+-----
 1 | i
 2 | ii
 3 | iii
 4 | iv
 5 | v
 6 | vi
(6 rows)

Observe that during normal replication the appropriate <literal>publish</literal> operations are used. This means publications <literal>pub2</literal> and <literal>pub3a</literal> will not replicate the <literal>INSERT</literal>. Also, publication <literal>pub3b</literal> will only replicate data that matches the row filter of <literal>pub3b</literal>. Now the subscriber side data looks like: 通常のレプリケーションでは、適切なパブリッシュ操作が使用されていることに注意してください。 これは、パブリケーションpub2およびpub3aがINSERTをレプリケーションしないことを意味します。 また、パブリケーションpub3bはpub3bの行フィルタに一致するデータのみをレプリケーションします。 サブスクライバー側のデータは次のようになります:

test_sub=# SELECT * FROM t1;
 a |   b
---+-------
 1 | one
 2 | two
 3 | three
 4 | four
 5 | five
 6 | six
(6 rows)

test_sub=# SELECT * FROM t2;
 c | d
---+---
 1 | A
 2 | B
 3 | C
(3 rows)

test_sub=# SELECT * FROM t3;
 e |  f
---+-----
 1 | i
 2 | ii
 3 | iii
 6 | vi
(4 rows)

There are some cases (e.g. <xref linkend="logical-replication-subscription-slot"/>) where, if the remote replication slot was not created automatically, the user must create it manually before the subscription can be activated. The steps to create the slot and activate the subscription are shown in the following examples. These examples specify the standard logical decoding plugin (<literal>pgoutput</literal>), which is what the built-in logical replication uses. 《機械翻訳》リモートレプリケーションスロットが自動的に作成されなかった場合（例えば31.2.1）、ユーザは、サブスクリプションをアクティブにする前に、手動で作成しなければなりません。 スロットを作成してサブスクリプションをアクティブ化する手順を、次の例に示します。 これらの例では、標準の論理デコードプラグイン（pgoutput）を指定しています。 これは、組み込みの論理レプリケーションが使用するものです。

First, create a publication for the examples to use. 《機械翻訳》まず、サンプルで使用するパブリケーションを作成します。

test_pub=# CREATE PUBLICATION pub1 FOR ALL TABLES;
CREATE PUBLICATION

Example 1: Where the subscription says <literal>connect = false</literal> 《機械翻訳》例1: 購読がconnect = falseと記述されている場合

Example 2: Where the subscription says <literal>connect = false</literal>, but also specifies the <link linkend="sql-createsubscription-with-slot-name"><literal>slot_name</literal></link> option. 《機械翻訳》例2: サブスクリプションがconnect=falseと記述されているが、connect=falseオプションも指定されている場合。

Example 3: Where the subscription specifies <literal>slot_name = NONE</literal> 《機械翻訳》例3: サブスクリプションがslot_name = NONEを指定する場合