Re: Logical Replication - behavior of TRUNCATE ... CASCADE
От | Bharath Rupireddy |
---|---|
Тема | Re: Logical Replication - behavior of TRUNCATE ... CASCADE |
Дата | |
Msg-id | CALj2ACWdUWVFZJ0UtFZdoUVJT6B46-VgKbDkEYvC3d9Toic_UA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Logical Replication - behavior of TRUNCATE ... CASCADE (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Logical Replication - behavior of TRUNCATE ... CASCADE
|
Список | pgsql-hackers |
On Mon, May 24, 2021 at 11:22 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > I don't deny that this can allow some additional cases than we allow > today but was just not sure whether users really need it. If we want > to go with such an option then as mentioned earlier, we should > consider another proposal for subscriber-side truncate [1] because we > might need a cascade operation there as well but for a slightly > different purpose. I'm thinking how we can utilize the truncate option proposed at [1] for the idea here. Because, currently the truncate option(proposed at [1]) is boolean, (of course we can change this to take "cascade", "restrict" options). But how can we differentiate the usage of the truncate option at [1] for two purposes 1) for before copy data/initial table sync operation and 2) for the replication of TRUNCATE command as proposed here in this thread. Any thoughts? [1] - https://www.postgresql.org/message-id/CALj2ACVWNBttS-YcMYuUPK25tsuqtbpuNjT-CBRQLUHXezWERw%40mail.gmail.com With Regards, Bharath Rupireddy. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: