agora inbox for pgsql-sql@postgresql.org
help / color / mirror / Atom feedFrom: Adrian Klaver <adrian.klaver@aklaver.com>
To: gmb <gmbouwer@gmail.com>
To: pgsql-sql@postgresql.org
Subject: Re: Disable Trigger for session only
Date: Mon, 29 Jun 2015 07:26:15 -0700
Message-ID: <55915587.2020606@aklaver.com> (raw)
In-Reply-To: <1435587185136-5855697.post@n5.nabble.com>
References: <1435563798887-5855658.post@n5.nabble.com>
<559142D5.2080608@aklaver.com>
<1435587185136-5855697.post@n5.nabble.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-sql>
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
view thread (8+ messages) latest in thread
Message-ID: <55915587.2020606@aklaver.com>
Permalink: ../55915587.2020606@aklaver.com/
Also on: postgresql.org/message-id/55915587.2020606@aklaver.com
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: adrian.klaver@aklaver.com, gmbouwer@gmail.com
Subject: Re: Disable Trigger for session only
In-Reply-To: <55915587.2020606@aklaver.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox