On 29 December 2017 at 22:14, Petr Jelinek <petr.jeli...@2ndquadrant.com> wrote:
> Hi, > > On 29/12/17 13:01, Marco Nenciarini wrote: > > Hi, > > > > The current behavior of session_replication_role = replica with TRUNCATE > > is not the same of with the other commands. > > It does not check FKs for INSERT/UPDATE/DELETE but it does for TRUNCATE, > > so one cannot execute TRUNCATE on a table when it is possible to DELETE > > from table without WHERE clause. > > > > Yes please, I never understood why 'DELETE FROM foo;' works fine with > 'session_replication_role = replica' and FKs while 'TRUNCATE foo;' would > throw error. > I've spent ages scratching my head about various ways to handle TRUNCATE and FKs on the downstream, and it never once occurred to me that session_replication_role should ignore FK cascades for replicated truncate. But it's really sensible to do just that. Sure, you can have dangling FKs, but the same is true if you create FKs from non-replicated tables pointing to replicated tables and do DELETEs from the replicated table, if your replication tool doesn't have some trick to stop you creating the FK. I'd still like to know if it was a cascade when applying it, so I can possibly make some client-determined behaviour choice, but that's for the other patch really. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
