vBulletin Search Engine Optimization
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| thanks for responding. Meanwhile I found out that ist was my own fault. A newly installed insert trigger fired unexpectedly and caused the error. Now I'm redesigning my functions to make them smaller so that errors can be found easier. Sometimes I wish there was something like a debugger for PL/PGSQL with breakpoints, single step, variable watching... Anyway, PostgreSQL is the best backend I ever have worked with. Regards --Marcel >>> Tom Lane <tgl@sss.pgh.pa.us> 13.01.2007 >>> "Marcel Gsteiger" <Marcel.Gsteiger@milprog.ch> writes: > Now since I upgraded to 8.2 I have problems inserting data into tables that have unique indexes. Ugly enough, I get the message 'duplicate key violates unique constraint' when inserting the very first record into a table. This happens everytime when the new tuple references another tuple that has been inserted just before this one in the same transaction. > Putting a "SET CONSTRAINTS ALL DEFERRED" in my procedure does not help. > To me it looks that something with referential integrity checking goes wrong, but in this case the error message would be misleading. RI would not have anything to do with a duplicate-key error. Do you have any SERIAL-type columns in these tables? My first thought is of a sequence that hasn't been updated to be above the existing ID values. It's fairly easy to get into such a state if you do anything but a plain vanilla dump-all-and-reload-all update process ... regards, tom lane ---------------------------(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 |
| ||||
| You can give EnterpriseDB PL Debugger a try, details for its usage can be found at --> http://www.enterprisedb.com/documentation/debugger.html -------------- Shoaib Mir EnterpriseDB (www.enterprisedb.com) On 1/14/07, Marcel Gsteiger <Marcel.Gsteiger@milprog.ch> wrote: > > thanks for responding. Meanwhile I found out that ist was my own fault. A > newly installed insert trigger fired unexpectedly and caused the error. Now > I'm redesigning my functions to make them smaller so that errors can be > found easier. Sometimes I wish there was something like a debugger for > PL/PGSQL with breakpoints, single step, variable watching... > Anyway, PostgreSQL is the best backend I ever have worked with. > > Regards > --Marcel > >>> Tom Lane <tgl@sss.pgh.pa.us> 13.01.2007 >>> > "Marcel Gsteiger" <Marcel.Gsteiger@milprog.ch> writes: > > Now since I upgraded to 8.2 I have problems inserting data into tables > that have unique indexes. Ugly enough, I get the message 'duplicate key > violates unique constraint' when inserting the very first record into a > table. This happens everytime when the new tuple references another tuple > that has been inserted just before this one in the same transaction. > > > Putting a "SET CONSTRAINTS ALL DEFERRED" in my procedure does not help. > > > To me it looks that something with referential integrity checking goes > wrong, but in this case the error message would be misleading. > > RI would not have anything to do with a duplicate-key error. > > Do you have any SERIAL-type columns in these tables? My first thought > is of a sequence that hasn't been updated to be above the existing ID > values. It's fairly easy to get into such a state if you do anything > but a plain vanilla dump-all-and-reload-all update process ... > > regards, tom lane > > > ---------------------------(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 > |