Re: Change the default [tgenabled] for new "internal" triggers ? - Mailing list pgsql-general

From
Subject Re: Change the default [tgenabled] for new "internal" triggers ?
Date
Msg-id F3CBFBA88397EA498B22A05FFA9EC49D697BB4E3@MX22A.corp.emc.com
Whole thread Raw
In response to Re: Change the default [tgenabled] for new "internal" triggers ?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Change the default [tgenabled] for new "internal" triggers ?
List 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 by date:

Previous
From: "Gauthier, Dave"
Date:
Subject: Re: "OLD used in query that is not in a rule"
Next
From: Tom Lane
Date:
Subject: Re: Change the default [tgenabled] for new "internal" triggers ?