Thread: Problem: Referential Integrity Constraints lost
Hi i think a hit a major problem on 7.2.1.
I run 3 systems with postgresql 7.2.1.
Its a redhat 7.1 for development, a redhat 7.3 for production
and a FreeBSD 4.6.1RC2 for testing.
After long runs (with periodic (daily) vacuum analyze's)
i noticed that some of the triggers that implement referential integrity
constraints just disapeared.
Some of these triggers were still present on the FreeBSD system
(which has been idle for a month or so), whereas on the linux
systems they were absent.
Has any one have a clue??
Any comment would be really valuable at this moment of darkness.
Thanx.
==================================================================
Achilleus Mantzios
S/W Engineer
IT dept
Dynacom Tankers Mngmt
Nikis 4, Glyfada
Athens 16610
Greece
tel: +30-10-8981112
fax: +30-10-8981877
email: achill@matrix.gatewaynet.com
mantzios@softlab.ece.ntua.gr
Also i must that these lost triggers implement the parent table
side of the constraint, e.g.
CREATE TABLE VslSections(
id serial NOT NULL UNIQUE PRIMARY KEY,
name varchar(20) NOT NULL UNIQUE);
CREATE TABLE MachClasses(
id serial NOT NULL UNIQUE PRIMARY KEY,
name varchar(20) NOT NULL UNIQUE,
vslsecid int4 NOT NULL,
FOREIGN KEY (vslsecid) REFERENCES VslSections (id));
Then the triggers created are :
1)
CREATE CONSTRAINT TRIGGER "<unnamed>" AFTER INSERT OR UPDATE ON
"machclasses" FROM "vslsections" NOT DEFERRABLE INITIALLY IMMEDIATE FOR
EACH ROW EXECUTE PROCEDURE "RI_FKey_check_ins" ('<unnamed>',
'machclasses', 'vslsections', 'UNSPECIFIED', 'vslsecid', 'id');
2)
CREATE CONSTRAINT TRIGGER "<unnamed>" AFTER DELETE ON "vslsections" FROM
"machclasses" NOT DEFERRABLE INITIALLY IMMEDIATE FOR EACH ROW EXECUTE
PROCEDURE "RI_FKey_noaction_del" ('<unnamed>', 'machclasses',
'vslsections', 'UNSPECIFIED', 'vslsecid', 'id');
3)
CREATE CONSTRAINT TRIGGER "<unnamed>" AFTER UPDATE ON "vslsections" FROM
"machclasses" NOT DEFERRABLE INITIALLY IMMEDIATE FOR EACH ROW EXECUTE
PROCEDURE "RI_FKey_noaction_upd" ('<unnamed>', 'machclasses',
'vslsections', 'UNSPECIFIED', 'vslsecid', 'id');
The *LOST* triggers are 2 and 3.
==================================================================
Achilleus Mantzios
S/W Engineer
IT dept
Dynacom Tankers Mngmt
Nikis 4, Glyfada
Athens 16610
Greece
tel: +30-10-8981112
fax: +30-10-8981877
email: achill@matrix.gatewaynet.com
mantzios@softlab.ece.ntua.gr
I was wrong about parent side triggers only having
disappeared.
Triggers of both sides are missing.
==================================================================
Achilleus Mantzios
S/W Engineer
IT dept
Dynacom Tankers Mngmt
Nikis 4, Glyfada
Athens 16610
Greece
tel: +30-10-8981112
fax: +30-10-8981877
email: achill@matrix.gatewaynet.com
mantzios@softlab.ece.ntua.gr
On Wed, 6 Nov 2002, Achilleus Mantzios wrote: > > Hi i think a hit a major problem on 7.2.1. > I run 3 systems with postgresql 7.2.1. > Its a redhat 7.1 for development, a redhat 7.3 for production > and a FreeBSD 4.6.1RC2 for testing. > > After long runs (with periodic (daily) vacuum analyze's) > i noticed that some of the triggers that implement referential integrity > constraints just disapeared. > Some of these triggers were still present on the FreeBSD system > (which has been idle for a month or so), whereas on the linux > systems they were absent. > > Has any one have a clue?? Hmm, you haven't done anything like cluster or an incomplete dump and reload have you?
On Wed, 6 Nov 2002, Stephan Szabo wrote:
> On Wed, 6 Nov 2002, Achilleus Mantzios wrote:
>
> >
> > Hi i think a hit a major problem on 7.2.1.
> > I run 3 systems with postgresql 7.2.1.
> > Its a redhat 7.1 for development, a redhat 7.3 for production
> > and a FreeBSD 4.6.1RC2 for testing.
> >
> > After long runs (with periodic (daily) vacuum analyze's)
> > i noticed that some of the triggers that implement referential integrity
> > constraints just disapeared.
> > Some of these triggers were still present on the FreeBSD system
> > (which has been idle for a month or so), whereas on the linux
> > systems they were absent.
> >
> > Has any one have a clue??
>
> Hmm, you haven't done anything like cluster or an incomplete dump and
> reload have you?
No,
Also the FreeBSD system's database was populated with data from
the production on 2002-10-22, so the problem on the FreeBSD
was partially inherited from the production databse.
>
>
>
==================================================================
Achilleus Mantzios
S/W Engineer
IT dept
Dynacom Tankers Mngmt
Nikis 4, Glyfada
Athens 16610
Greece
tel: +30-10-8981112
fax: +30-10-8981877
email: achill@matrix.gatewaynet.com
mantzios@softlab.ece.ntua.gr
On Thu, 7 Nov 2002, Achilleus Mantzios wrote:
> On Wed, 6 Nov 2002, Stephan Szabo wrote:
>
> > On Wed, 6 Nov 2002, Achilleus Mantzios wrote:
> >
> > >
> > > Hi i think a hit a major problem on 7.2.1.
> > > I run 3 systems with postgresql 7.2.1.
> > > Its a redhat 7.1 for development, a redhat 7.3 for production
> > > and a FreeBSD 4.6.1RC2 for testing.
> > >
> > > After long runs (with periodic (daily) vacuum analyze's)
> > > i noticed that some of the triggers that implement referential integrity
> > > constraints just disapeared.
> > > Some of these triggers were still present on the FreeBSD system
> > > (which has been idle for a month or so), whereas on the linux
> > > systems they were absent.
> > >
> > > Has any one have a clue??
> >
> > Hmm, you haven't done anything like cluster or an incomplete dump and
> > reload have you?
>
> No,
> Also the FreeBSD system's database was populated with data from
> the production on 2002-10-22, so the problem on the FreeBSD
> was partially inherited from the production databse.
Also i must add, that the database on the production system
was never dumped/reloaded since the creation of the system.
The production 7.2.1 pgsql db was created and loaded on 2002-04-20,
from a 7.1.3 pgsql on our previous Solaris box (which we replaced
with a new linux one).
The production pgsql is started/stopped only during
system shutdowns/boots.
We had some unexpected system failures due to some
Linux/MotherBoard/BIOS problems.
(I was too enthusiastic about pgsql and its stability
that i was overconfident about our database's state
after these failures).
BTW, could that be the cause of the problem??
The problem is that i didnt realize the problem until yesterday.
The only thing i am sure, is that some of the triggers lost
one both linux'es are present on the FreeBSD system,
which was populated on Oct 22, and had NO deletion activity
at all.
I plan to make a huge map of all my tables, and configure
all the pairs of tables with inter-referential integrity constraints,
pg_dump --schema-only, see which triggers are missing
and then create them by hand.
Has anyone got a better idea??
After recreating the missing triggers should i upgrade
to 7.2.3??
Thanx.
>
> >
> >
> >
>
> ==================================================================
> Achilleus Mantzios
> S/W Engineer
> IT dept
> Dynacom Tankers Mngmt
> Nikis 4, Glyfada
> Athens 16610
> Greece
> tel: +30-10-8981112
> fax: +30-10-8981877
> email: achill@matrix.gatewaynet.com
> mantzios@softlab.ece.ntua.gr
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>
==================================================================
Achilleus Mantzios
S/W Engineer
IT dept
Dynacom Tankers Mngmt
Nikis 4, Glyfada
Athens 16610
Greece
tel: +30-10-8981112
fax: +30-10-8981877
email: achill@matrix.gatewaynet.com
mantzios@softlab.ece.ntua.gr
Achilleus Mantzios <achill@matrix.gatewaynet.com> writes:
> After recreating the missing triggers should i upgrade
> to 7.2.3??
Make that "before".
I frankly suspect pilot error here. Triggers do not simply disappear.
If you did have crash-induced corruption leading to loss of some rows
in pg_trigger, it would be exceedingly obvious because *no* operations
on the affected tables would work --- relcache would complain about the
fact that pg_class.reltriggers didn't match the number of rows in
pg_trigger. I think the missing triggers must have been removed or
disabled deliberately. (Which is not to say that it couldn't have been
a software bug, but you're barking up the wrong tree to blame it on a
crash.)
Did all the triggers of the affected tables disappear, or only some
of them?
regards, tom lane
On Thu, 7 Nov 2002, Tom Lane wrote:
> Achilleus Mantzios <achill@matrix.gatewaynet.com> writes:
> > After recreating the missing triggers should i upgrade
> > to 7.2.3??
>
> Make that "before".
>
> I frankly suspect pilot error here. Triggers do not simply disappear.
> If you did have crash-induced corruption leading to loss of some rows
> in pg_trigger, it would be exceedingly obvious because *no* operations
> on the affected tables would work --- relcache would complain about the
> fact that pg_class.reltriggers didn't match the number of rows in
> pg_trigger. I think the missing triggers must have been removed or
> disabled deliberately. (Which is not to say that it couldn't have been
> a software bug, but you're barking up the wrong tree to blame it on a
> crash.)
> Did all the triggers of the affected tables disappear, or only some
> of them?
Just some of them.
I really dont know what happened.
Looking back at july backups the problem was already there.
I never played with system tables in production.
I hope to be able somehow to reproduce the problem,
or convince myself its my fault for some reason.
P.S.
I was surprized when i looked up in my english dictionary the
word "deliberately" :)
>
> regards, tom lane
>
==================================================================
Achilleus Mantzios
S/W Engineer
IT dept
Dynacom Tankers Mngmt
Nikis 4, Glyfada
Athens 16610
Greece
tel: +30-10-8981112
fax: +30-10-8981877
email: achill@matrix.gatewaynet.com
mantzios@softlab.ece.ntua.gr