Re: Change the default [tgenabled] for new "internal" triggers ?

Поиск
Список
Период
Сортировка
От
Тема Re: Change the default [tgenabled] for new "internal" triggers ?
Дата
Msg-id F3CBFBA88397EA498B22A05FFA9EC49D697BB4E3@MX22A.corp.emc.com
обсуждение исходный текст
Ответ на Re: Change the default [tgenabled] for new "internal" triggers ?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Change the default [tgenabled] for new "internal" triggers ?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
Scenario: (not slony, it is home-grown replication)

A change on the Primary db is Captured and then Propagated to the Secondary db.
Then the change is Applied to the Secondary db, with [session_replication_role] = 'replica'.

I agree that I don't want my "user triggers" to fire as part of the Apply.

But my email was about the "internally generated constraint triggers"
which implement checking for Foreign Key Constraint violations.

It is that checking that I want to be done on the Secondary.
Should I not want such checking to be done ?

Thanks,
-dvs-

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Friday, March 23, 2012 8:35 PM
To: Sahagian, David
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Change the default [tgenabled] for new "internal" triggers ?

<david.sahagian@emc.com> writes:
> Is the a way to configure Postgres such that tgenabled = ' A' automatically when the FK constraint gets made ?

No.  Why do you think that would be a good idea?  ISTM it'd lead to the
action being taken twice on the slave.

            regards, tom lane


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

Предыдущее
От: "Gauthier, Dave"
Дата:
Сообщение: Re: "OLD used in query that is not in a rule"
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Change the default [tgenabled] for new "internal" triggers ?