Re: [PATCH] session_replication_role = replica with TRUNCATE

Поиск
Список
Период
Сортировка
От Marco Nenciarini
Тема Re: [PATCH] session_replication_role = replica with TRUNCATE
Дата
Msg-id ee17c777-d9ba-ae14-f461-e265d2ab0b7a@2ndquadrant.it
обсуждение исходный текст
Ответ на Re: [PATCH] session_replication_role = replica with TRUNCATE  (Craig Ringer <craig@2ndquadrant.com>)
Ответы Re: [PATCH] session_replication_role = replica with TRUNCATE
Список pgsql-hackers
Hi,

Il 30/12/17 08:42, Craig Ringer ha scritto:
> On 30 December 2017 at 03:32, Petr Jelinek <petr.jelinek@2ndquadrant.com
> <mailto:petr.jelinek@2ndquadrant.com>> wrote:
>
>     On 29/12/17 16:53, Marco Nenciarini wrote:
>     > Il 29/12/17 15:14, Petr Jelinek ha scritto:
>     >>
>     >> May be worth documenting that the session_replication_role also affects
>     >> TRUNCATE's interaction with FKs in config.sgml.
>     >>
>     >
>     > The current documentation of session_replication_role GUC is:
>     >
>     >     Controls firing of replication-related triggers and rules for the
>     >     current session. Setting this variable requires superuser privilege
>     >     and results in discarding any previously cached query plans.
>     >     Possible values are origin (the default), replica and local.
>     >     See ALTER TABLE for more information.
>     >
>     > It doesn't speak about foreign keys or referential integrity, but only
>     > about triggers and rules. I don't think that it's worth to add a special
>     > case for truncate, unless we want to expand/rewrite the documentation to
>     > specify all the effects in the details.
>     >
>
>     The effects on foreign keys is implied by the fact that for DML it's
>     implemented using triggers, but that's not true for TRUNCATE. In any
>     case it does not hurt to mention the FKs explicitly rather than
>     implicitly here.
>
>
> Yeah. I'd argue that's an oversight in the current docs that "can cause
> FK violations" isn't mentioned. That's kind of important, and FKs being
> triggers is implementation detail we shouldn't be relying on users to know. 
>

I've tried to amend the documentation to be more clear. Feel free to
suggest further editing. Patch v2 attached.

Regards,
Marco

P.S: I'm struggling to understand why we have two possible values of
session_replication_role settings that behave identically (origin and
local). I'm unable to see any difference according to the code or the
documentation, so I'm wondering if we should document that they are the
same.

--
Marco Nenciarini - 2ndQuadrant Italy
PostgreSQL Training, Services and Support
marco.nenciarini@2ndQuadrant.it | www.2ndQuadrant.it

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jesper Pedersen
Дата:
Сообщение: Re: [HACKERS] Fix performance degradation of contended LWLock on NUMA
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Better testing coverage and unified coding for plpgsql loops