Re: too many trigger records found for relation "item" -

Nevertheless, the database should be able to handle any combination of
syntactically correct SQL statements without throwing errors and
maintaining the database in a consistent state.  If what you're saying
is right, the error thrown here is not a user configuration error, but
an RDBMS implementation error.

A development database is still obviously an important role for
PostgreSQL to function in (as far as PostgreSQL's dev team is concerned,
a development database *is* a "production" use since once of *their*
end-users experiences the problem) and it needs to be able to handle
cases such as this with no problems.  And no matter how unlikely it is
to be in a production environment, *someone* will try to modify their
schema dynamically like this.

I'm wondering if there is a race condition in CREATE or DROP with
respect to triggers and foreign keys.  If that's the case, it's going to
affect someone eventually.

--
Brandon Aiken
CS/IT Systems Engineer

-----Original Message-----
From: pgsql-general-owner@postgresql.org
[mailto:pgsql-general-owner@postgresql.org] On Behalf Of Csaba Nagy
Sent: Tuesday, January 23, 2007 4:42 AM
To: Lenorovitz, Joel
Cc: Postgres general mailing list
Subject: Re: [GENERAL] too many trigger records found for relation
"item" -

On Mon, 2007-01-22 at 20:56, Lenorovitz, Joel wrote:
[snip]
> ERROR:  too many trigger records found for relation "item"

I've got this error on a development data base where we were
continuously creating new child tables referencing the same parent
table. 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. In any case it should be a transient error,
i.e. it should only happen when you heavily create/drop triggers... our
integration test case was actually heavily creating new child tables, so
that's how it happened for us.

In a production scenario I won't be creating all the time new triggers
in parallel with other heavy activities, so it doesn't bother me.

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


--------------------------------------------------------------------
** LEGAL DISCLAIMER **
Statements made in this email may or may not reflect the views and opinions of Wineman Technology, Inc.
This E-mail message and any attachments may contain legally privileged, confidential or proprietary information. If you
arenot the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended
recipient(s),you are hereby notified that any dissemination, distribution or copying of this E-mail message is strictly
prohibited.If you have received this message in error, please immediately notify the sender and delete this E-mail
messagefrom your computer. 

QS Disclaimer Demo. Copyright (C) Pa-software.
Visit www.pa-software.com for more information.