From: | Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com> |
---|---|
To: | Marco Nenciarini <marco(dot)nenciarini(at)2ndquadrant(dot)it>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] session_replication_role = replica with TRUNCATE |
Date: | 2017-12-29 14:14:07 |
Message-ID: | 2e689636-51cd-aa19-c7a2-435051fbc9cd@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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'm attaching a simple patch to make TRUNCATE match behavior of DELETE
> for session_replication_role = replica.
>
May be worth documenting that the session_replication_role also affects
TRUNCATE's interaction with FKs in config.sgml.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2017-12-29 14:17:41 | Re: Add hint about replication slots when nearing wraparound |
Previous Message | David Steele | 2017-12-29 14:11:12 | Re: Basebackups reported as idle |