Message-ID: <55915587.2020606@aklaver.com>
Date: Mon, 29 Jun 2015 07:26:15 -0700
From: Adrian Klaver <adrian.klaver@aklaver.com>
User-Agent: Mozilla/5.0 (X11; Linux i686;
 rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: gmb <gmbouwer@gmail.com>, pgsql-sql@postgresql.org
Subject: Re: Disable Trigger for session only
References: <1435563798887-5855658.post@n5.nabble.com>
 <559142D5.2080608@aklaver.com> <1435587185136-5855697.post@n5.nabble.com>
In-Reply-To: <1435587185136-5855697.post@n5.nabble.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-sql-owner@postgresql.org

On 06/29/2015 07:13 AM, gmb wrote:
> Adrian Klaver-4 wrote
>>>
>>> Some notes:
>>> It cannot be guaranteed that the above happens as a single transaction.
>>> It is possible that this occurs at the same time as other session posting
>>> inserts/updates to table TEMP.
>>
>> It can if wrapped in BEGIN/COMMIT or is there reason that is not being
>> done?
>
> Sorry , what I meant to say was that as this stage this is not implemented
> in a single transaction (with BEGIN/COMMIT).
>
>
> Adrian Klaver-4 wrote
>>> I'm seeing data which suggests that trigger trigname did not occur when
>>> in
>>> fact it should have ( i.e. the above update procedure is not relevant ).
>>> Does this make sense taking into account that multiple sessions posts to
>>> the
>>> table at once ?
>>
>> Not without knowing what the trigger procedure does?
>
> The trigger being disabled is used to post summarized numeric values to a
> summary table.
> Actually what I'm trying to do here is to reset the values in the detail
> table to zero without updating the summary tables. Afterwards I'm updating
> from a zero value which means that the difference will be posted to the
> summary table. This kind of data fix is required where data on the summary
> tables was not posted as excepted for whatever reason.
>
>
> I guess my question is:
> If I encapsulate the "disable trigger/update/enable trigger" in BEGIN/COMMIT
> to handle as single transaction, are there guarantees that the disabling of
> the trigger will not have an effect on other sessions ?

That I do not know. A thought did come to mind though. That is to add a 
reset boolean column(default ='f') to your detail table and make the 
trigger procedure aware of it. Then when you are resetting the values to 
zero have reset = 't' and have the trigger procedure ignore those rows. 
Then do the 'normal' update to update the summary table.

>
>
>
> --
> View this message in context: http://postgresql.nabble.com/Disable-Trigger-for-session-only-tp5855658p5855697.html
> Sent from the PostgreSQL - sql mailing list archive at Nabble.com.
>
>


-- 
Adrian Klaver
adrian.klaver@aklaver.com


-- 
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql