A logical slot will emit each change just once in normal operation.
The current position of each slot is persisted only at checkpoint, so in
the case of a crash the slot may return to an earlier LSN, which will
- then cause recent changes to be resent when the server restarts.
+ then cause recent changes to be sent again when the server restarts.
Logical decoding clients are responsible for avoiding ill effects from
handling the same message more than once. Clients may wish to record
the last LSN they saw when decoding and skip over any repeated data or
from the parent table will be created in the partition, if they don't
already exist.
If any of the <literal>CHECK</literal> constraints of the table being
- attached is marked <literal>NO INHERIT</literal>, the command will fail;
+ attached are marked <literal>NO INHERIT</literal>, the command will fail;
such constraints must be recreated without the
<literal>NO INHERIT</literal> clause.
</para>
<para>
It is safe to use <literal>off</literal> for logical replication:
If the subscriber loses transactions because of missing
- synchronization, the data will be resent from the publisher.
+ synchronization, the data will be sent again from the publisher.
</para>
<para>
specify suppression of the <literal>CONTEXT:</literal> portion of a message in
the postmaster log. This should only be used for verbose debugging
messages where the repeated inclusion of context would bloat the log
- volume too much.
+ too much.
</para>
</listitem>
</itemizedlist>
else
LWLockRelease(ProcArrayLock);
- /* prevent signal from being resent more than once */
+ /* prevent signal from being sent again more than once */
allow_autovacuum_cancel = false;
}