From: | Csaba Nagy <nagy(at)ecircle-ag(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Lenorovitz, Joel" <Joel(dot)Lenorovitz(at)usap(dot)gov>, Postgres general mailing list <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: too many trigger records found for relation "item" - |
Date: | 2007-01-23 15:51:39 |
Message-ID: | 1169567499.2735.106.camel@coppola.muc.ecircle.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, 2007-01-23 at 15:43, Tom Lane wrote:
> Csaba Nagy <nagy(at)ecircle-ag(dot)com> writes:
> > The responsible code is in src/backend/commands/trigger.c, and I
> > think it only happens if you manage to create/drop a new trigger (which
> > also could be a FK trigger created by a new foreign key referencing that
> > table, as in our case) exactly between that code gets the count of the
> > triggers and processes them.
>
> All such code takes exclusive lock on the table, so the above
> explanation is impossible.
Well, in that case it must be some other bug as it is readily
reproducible here. My nightly integration has this error each night. The
reason I don't panic (although I thought I reported it, but I can't find
the mail) is that rerunning the failed things succeeds, and the failed
operation is a table creation which is never critical for us in the
sense that it can be retried as many times as necessary.
The test data base is an 8.1.3 installation. The queries failing for the
last run were:
- an insert into the parent table;
- a create table which was creating a child table to the same parent
table the other query was inserting;
I'm not sure if the 2 failures were connected or not.
I also can't confirm if it also happens on 8.2 as my integration is
still not running through on 8.2...
Cheers,
Csaba.
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2007-01-23 15:56:54 | Re: Regular expressions and arrays and ANY() question |
Previous Message | Subramaniam Aiylam | 2007-01-23 15:47:26 | Postgres processes have a burst of CPU usage |