Re: LOST REFERENTIAL INTEGRITY - Mailing list pgsql-general

From Jimmie H. Apsey
Subject Re: LOST REFERENTIAL INTEGRITY
Date
Msg-id 4161BFE7.80407@futuredental.com
Whole thread Raw
In response to Re: LOST REFERENTIAL INTEGRITY  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: LOST REFERENTIAL INTEGRITY
Re: LOST REFERENTIAL INTEGRITY
List pgsql-general
Tom Lane wrote:
"Jimmie H. Apsey" <japsey@futuredental.com> writes: 
Each FK constraint should have three associated triggers (two on the
referencing table, one on the referenced table).     
 
OH, that's very scary for me that triggers can vanish/be eliminated w/o 
my direct action.  Yes, I do now see that the triggers on my production 
table have been lost.  I built a test table and they appear as 
expected.  Is there any way I can prevent this or become aware that 
something had done this to my production database?   
If you are still running 7.1 you obviously do not know the meaning of
the word "fear" ;-) --- it not only has lots of since-fixed bugs, but
at that time we hadn't yet solved the transaction ID wraparound problem,
which means your DB is guaranteed to self-destruct once you reach the
4-billion-transaction mark.

I'd recommend an upgrade to 7.4.5 at your earliest convenience.
		regards, tom lane
 
I have kept up-to-date our Red Hat kernels as you can probably see from the Linux 2.4.9-e.49smp kernel.  Am I required to maintain my own version of Postgres alongside and compiled into Red Hat's latest and greatest kernel?  If that's true, WHEW!  I wonder what version of Postgres is installed in Red Hat's latest kernel of AS 3.0?

pgsql-general by date:

Previous
From: Wiebe de Jong
Date:
Subject: Cursors and JDBC
Next
From: Martijn van Oosterhout
Date:
Subject: Re: LOST REFERENTIAL INTEGRITY