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@xxxxxxxxxxxxxx [mailto:pgsql-general-owner@xxxxxxxxxxxxxx] 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 are not 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 message from your computer. QS Disclaimer Demo. Copyright (C) Pa-software. Visit www.pa-software.com for more information.
