On 26/01/18 03:44, Peter Eisentraut wrote:
> On 1/24/18 07:53, Petr Jelinek wrote:
>> That depends on if we consider this to be part of sequence handling or
>> truncate statement replication handling. It's true that if we had
>> sequence replication, the restart would get propagated that way anyway.
>> OTOH, if we'll want to add option in the future to propagate cascade (to
>> any additional tables on downstream), it may need to reset sequences
>> which are not even present upstream and as such would not be handled by
>> sequence replication.
>
> Logical replication, as it currently is designed, replicates discrete
> actions, not commands. A delete command that deletes five rows and
> cascades to delete three more rows somewhere else ends up being
> replicated as eight changes. So I think a TRUNCATE command that
> cascades to four tables and resets six sequences should end up being
> replicated as ten changes. (Since we currently don't handle sequences
> at all, we'll omit the six sequence changes for now.)
>
Well, that depends, I think there are two separate problems a) decoding
b) replication.
I think it's useful for plugins to know if reset sequence or cascade was
specified in the command so I think it should be decoded. Some plugins
will definitely want to forward that info.
But it's true that since we don't handle sequences in logical
replication, the sequence reset does not need to be replicated there.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services