By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,777 Members | 1,755 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,777 IT Pros & Developers. It's quick & easy.

Trigger

P: n/a
Is it possible to deferr a trigger until commit, Or to have the
trigger not occur if the transaction is rolled back? Like transaction.
I think its possible since constraints use triggers and if so why
is this a standard feature.
Also is there anyway of seeing what triggers exsist and what they
do? (psql \<somthing> or the like)

Peter Childs

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

Nov 12 '05 #1
Share this Question
Share on Google+
11 Replies


P: n/a
On Wed, 22 Oct 2003, Peter Childs wrote:
Is it possible to deferr a trigger until commit, Or to have the
trigger not occur if the transaction is rolled back? Like transaction.
I think its possible since constraints use triggers and if so why
is this a standard feature.
Also is there anyway of seeing what triggers exsist and what they
do? (psql \<somthing> or the like)


A trigger inside a transaction should automagically roll back should the
transaction fail, shouldn't it?
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

Nov 12 '05 #2

P: n/a
scott.marlowe writes:
A trigger inside a transaction should automagically roll back should the
transaction fail, shouldn't it?


The database actions that the trigger possibly executed are rolled back
just like any other database actions. But if your trigger does something
external to the database, you have a problem (that borders on
unsolvable).

--
Peter Eisentraut pe*****@gmx.net
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 12 '05 #3

P: n/a


On Wed, 22 Oct 2003, scott.marlowe wrote:
On Wed, 22 Oct 2003, Peter Childs wrote:
Is it possible to deferr a trigger until commit, Or to have the
trigger not occur if the transaction is rolled back? Like transaction.
I think its possible since constraints use triggers and if so why
is this a standard feature.
Also is there anyway of seeing what triggers exsist and what they
do? (psql \<somthing> or the like)


A trigger inside a transaction should automagically roll back should the
transaction fail, shouldn't it?


Only if it only affects that database. If the trigger uses C to
tell an outside app whats going on, it will not get the truth.
Background, we are trying to get the database to tell clients when
records get updated, deleted or inserted so that they can update there
on-screen displays without having to query the database every couple of
seconds which would put an unnessary strain on the database. Hence
producing quicker respose times.

Peter Childs

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Nov 12 '05 #4

P: n/a
On Thu, Oct 23, 2003 at 08:16:27AM +0100, Peter Childs wrote:


On Wed, 22 Oct 2003, scott.marlowe wrote:
On Wed, 22 Oct 2003, Peter Childs wrote:
Is it possible to deferr a trigger until commit, Or to have the
trigger not occur if the transaction is rolled back? Like transaction.


Background, we are trying to get the database to tell clients when
records get updated, deleted or inserted so that they can update there
on-screen displays without having to query the database every couple of
seconds which would put an unnessary strain on the database. Hence
producing quicker respose times.


You should probably be using an AFTER trigger ... when those get
executed, the transaction is ready to commit and will not abort (barring
any major problems, like your server go nuts or something).

But why don't you use some notifications and set up appropiate listeners
on the OSDs? See the NOTIFY/LISTEN reference pages ... these also get
delivered during transaction commit.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"In fact, the basic problem with Perl 5's subroutines is that they're not
crufty enough, so the cruft leaks out into user-defined code instead, by
the Conservation of Cruft Principle." (Larry Wall, Apocalypse 6)

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 12 '05 #5

P: n/a


On Thu, 23 Oct 2003, Alvaro Herrera wrote:
On Thu, Oct 23, 2003 at 08:16:27AM +0100, Peter Childs wrote:


On Wed, 22 Oct 2003, scott.marlowe wrote:
On Wed, 22 Oct 2003, Peter Childs wrote:

> Is it possible to deferr a trigger until commit, Or to have the
> trigger not occur if the transaction is rolled back? Like transaction.
Background, we are trying to get the database to tell clients when
records get updated, deleted or inserted so that they can update there
on-screen displays without having to query the database every couple of
seconds which would put an unnessary strain on the database. Hence
producing quicker respose times.


You should probably be using an AFTER trigger ... when those get
executed, the transaction is ready to commit and will not abort (barring
any major problems, like your server go nuts or something).


Using an After trigger but the transactions may still rollback. a
subsquent query may fail before commit or a constraint may fail.

But why don't you use some notifications and set up appropiate listeners
on the OSDs? See the NOTIFY/LISTEN reference pages ... these also get
delivered during transaction commit.
Great idea shame drivers to get at these are rare. Anyway you
still need a trigger to fire the notify and these get sent when the query
is done not when its commented. hmmm
Peter Childs

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"In fact, the basic problem with Perl 5's subroutines is that they're not
crufty enough, so the cruft leaks out into user-defined code instead, by
the Conservation of Cruft Principle." (Larry Wall, Apocalypse 6)


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Nov 12 '05 #6

P: n/a
Peter Childs <bl*********@blueyonder.co.uk> writes:
Background, we are trying to get the database to tell clients when
records get updated, deleted or inserted so that they can update there
on-screen displays without having to query the database every couple of
seconds which would put an unnessary strain on the database.


Use LISTEN/NOTIFY.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

Nov 12 '05 #7

P: n/a
Peter Childs <bl*********@blueyonder.co.uk> writes:
Great idea shame drivers to get at these are rare. Anyway you
still need a trigger to fire the notify and these get sent when the query
is done not when its commented. hmmm


But the NOTIFY isn't delivered until and unless the transaction commits.
This gets around the AFTER-trigger-can-still-roll-back problem.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Nov 12 '05 #8

P: n/a
On Thu, 23 Oct 2003, Alvaro Herrera wrote:
On Thu, Oct 23, 2003 at 08:16:27AM +0100, Peter Childs wrote:


On Wed, 22 Oct 2003, scott.marlowe wrote:
On Wed, 22 Oct 2003, Peter Childs wrote:

> Is it possible to deferr a trigger until commit, Or to have the
> trigger not occur if the transaction is rolled back? Like transaction.


Background, we are trying to get the database to tell clients when
records get updated, deleted or inserted so that they can update there
on-screen displays without having to query the database every couple of
seconds which would put an unnessary strain on the database. Hence
producing quicker respose times.


You should probably be using an AFTER trigger ... when those get
executed, the transaction is ready to commit and will not abort (barring
any major problems, like your server go nuts or something).


This is not true, actually. After triggers generally happen at the end of
statement (with the exception of deferred constraint triggers and some
wierdness with functions) and can themselves throw an exception condition
so even barring internal problems, it's unsafe to assume that an exception
won't happen after your trigger runs.

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Nov 12 '05 #9

P: n/a


On Thu, 23 Oct 2003, Tom Lane wrote:
Peter Childs <bl*********@blueyonder.co.uk> writes:
Great idea shame drivers to get at these are rare. Anyway you
still need a trigger to fire the notify and these get sent when the query
is done not when its commented. hmmm


But the NOTIFY isn't delivered until and unless the transaction commits.
This gets around the AFTER-trigger-can-still-roll-back problem.

regards, tom lane

Notify is also not very flexable it tells you somthing has
triggerged it not the information that a trigger is supplied with, like
what has changed to what from what.

Peter Childs

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Nov 12 '05 #10

P: n/a
On Thu, 23 Oct 2003, Peter Childs wrote:


On Wed, 22 Oct 2003, scott.marlowe wrote:
On Wed, 22 Oct 2003, Peter Childs wrote:
Is it possible to deferr a trigger until commit, Or to have the
trigger not occur if the transaction is rolled back? Like transaction.
I think its possible since constraints use triggers and if so why
is this a standard feature.
Also is there anyway of seeing what triggers exsist and what they
do? (psql \<somthing> or the like)


A trigger inside a transaction should automagically roll back should the
transaction fail, shouldn't it?


Only if it only affects that database. If the trigger uses C to
tell an outside app whats going on, it will not get the truth.
Background, we are trying to get the database to tell clients when
records get updated, deleted or inserted so that they can update there
on-screen displays without having to query the database every couple of
seconds which would put an unnessary strain on the database. Hence
producing quicker respose times.


It might be more efficient and transactionally safe to write it all to a
temp table, and have a daemon suck that data out every now and then and
put it into another database that the feeders can interrogate as often as
they like. that way you still get the ease of programming a transaction
that's all or nothing, and since the daemon only runs every minute or two
and batches up its access, the impace of the batching should be nominal.
Or would that introduce other problems of its own?
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Nov 12 '05 #11

P: n/a


On Thu, 23 Oct 2003, scott.marlowe wrote:
It might be more efficient and transactionally safe to write it all to a
temp table, and have a daemon suck that data out every now and then and
put it into another database that the feeders can interrogate as often as
they like. that way you still get the ease of programming a transaction
that's all or nothing, and since the daemon only runs every minute or two
and batches up its access, the impace of the batching should be nominal.
Or would that introduce other problems of its own?

Makes the whole trigger alot more complex. Also got to work out
when to remove rows. Plus a load of programming to get notify to work
properly. Yuk.

I think the simplest way then is going to be. That your
surgesting.

Write Trigger to Write info to table and notify each row needs a unique
id.

Listening Program reads table and records another id to say its
listening and how far its got, Waits for notify then checks the table
again and records the id. Fortinally each transaction only emits one
notify no matter how many times notify got called.

Program three looks for all ids in table below the lowest id listen and
deletes them, this should keep the table small enough to use.

Where as my orignal plan was using a deffered after trigger emit
the data down a pipe then all the program needs to do is listen to the
pipe.

Both plans have advantages the main oneof mine being its simple.

Peter
Trying to follow a kiss policy.

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

Nov 12 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.