Re: [BUGS] BUG #14771: "Logical decoding" does not cover the impactof "TRUNCATE TABLE" command
От | Andres Freund |
---|---|
Тема | Re: [BUGS] BUG #14771: "Logical decoding" does not cover the impactof "TRUNCATE TABLE" command |
Дата | |
Msg-id | 20170807203432.zb4wv2hr34s2mya2@alap3.anarazel.de обсуждение исходный текст |
Ответ на | [BUGS] BUG #14771: "Logical decoding" does not cover the impact of "TRUNCATETABLE" command (hillel.eilat@attunity.com) |
Ответы |
Re: [BUGS] BUG #14771: "Logical decoding" does not cover the impactof "TRUNCATE TABLE" command
|
Список | pgsql-bugs |
Hi, On 2017-08-07 12:20:30 +0000, hillel.eilat@attunity.com wrote: > From "Logical Decoding" perspective - "TRUNCATE TABLE" is logically > equivalent to "DELETE FROM TABLE". It's absolutely not. A DELETE FROM TABLE has to include all the deleted rows (think of concurrency and servers that don't match), whereas a truncate doesn't include that. So changing TRUNCATE wouldn't be appropriate. > Both affect the contents of the PostgreSQL database identically. > However - "DELETE FROM TABLE" will be reflected at the target database > properly - as expected - while "TRUNCATE" will NOT!!. > "Logical Decoding" aims to cover ALL changes made onto data in a coherent > fashion. > "TRUNCATE" stands for a case where change in data contents at PostgreSQL are > not handled by "Logical Decoding", hence synchronization is not achieved. > Did I miss something? > Is it the only case? Others remarked on this. > How can one cope with this deficiency? The best solution imo is to have a TRUNCATE trigger that leads to the truncation being logged. Either by having a 'ddl commands' table, or by using wal messages. Greetings, Andres Freund -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
В списке pgsql-bugs по дате отправления: