target table can have additional columns not provided by the published

table. Those will be filled with their default values.

</para>

<sect2 id="logical-replication-subscription-slot">

<title>Replication Slot Management</title>

<para>

As mentioned earlier, each (active) subscription receives changes from a

replication slot on the remote (publishing) side. 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:

<itemizedlist>

<listitem>

<para>

When creating a subscription, the replication slot already exists. In

that case, the subscription can be created using the <literal>NOCREATE

SLOT</literal> option to associate with the existing slot.

</para>

</listitem>

<listitem>

<para>

When creating a subscription, the remote host is not reachable or in an

unclear state. In that case, the subscription can be created using

the <literal>NOCONNECT</literal> option. The remote host will then not

be contacted at all. This is what <application>pg_dump</application>

uses. The remote replication slot will then have to be created

manually before the subscription can be activated.

</para>

</listitem>

<listitem>

<para>

When dropping a subscription, the replication slot should be kept.

This could be useful when the subscriber database is being moved to a

different host and will be activated from there. In that case,

disassociate the slot from the subscription using <command>ALTER

SUBSCRIPTION</command> before attempting to drop the subscription.

</para>

</listitem>

<listitem>

<para>

When dropping a subscription, the remote host is not reachable. In

that case, disassociate the slot from the subscription

using <command>ALTER SUBSCRIPTION</command> before attempting to drop

the subscription. If the remote database instance no longer exists, no

further action is then necessary. If, however, the remote database

instance is just unreachable, the replication slot should then be

dropped manually; otherwise it would continue to reserve WAL and might

eventually cause the disk to fill up. Such cases should be carefully

investigated.

</para>

</listitem>

</itemizedlist>

</para>

</sect2>

</sect1>

<sect1 id="logical-replication-conflicts">