Re: [PATCH] session_replication_role = replica with TRUNCATE

On 29 December 2017 at 22:14, Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)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