On Tue, 2007-01-23 at 15:43, Tom Lane wrote:
> Csaba Nagy <[EMAIL PROTECTED]> 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.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
