Re: [PATCH] Logical decoding of TRUNCATE

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: [PATCH] Logical decoding of TRUNCATE
Дата
Msg-id 7f0589c2-c82e-27f3-9d2c-68c0a1bb0b6e@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: [PATCH] Logical decoding of TRUNCATE  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
Ответы Re: [PATCH] Logical decoding of TRUNCATE
Список pgsql-hackers
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.)

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: [HACKERS] Subscription code improvements
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: [PATCH][PROPOSAL] Refuse setting toast.* reloptions when TOASTtable does not exist