Re: Need help to identify stray row in a table
От | Merlin Moncure |
---|---|
Тема | Re: Need help to identify stray row in a table |
Дата | |
Msg-id | y2zb42b73151004231052we00bb4b8re56edff1c3cb0ca7@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Need help to identify stray row in a table (சிவகுமார் மா<masivakumar@gmail.com>) |
Ответы |
Re: Need help to identify stray row in a table
|
Список | pgsql-general |
2010/4/23 சிவகுமார் மா <masivakumar@gmail.com>: > 2010/4/23 Merlin Moncure <mmoncure@gmail.com>: >> >> You haven't given enough information to make any sort of reasonable >> diagnosis. Most people are going to assume the problem is on your end >> but it's possible to know for sure without having the trigger function >> at the very least. >> > > Thanks merlin for the reply. There are two functions, > > 1. for inserts on stock transaction table, calculating value and > inserting in transaction_value table. > > 2. the other is on transaction_value table itself, to update values of > child transactions of row being inserted/updated/deleted. > > The second function is more than 200 lines. I have attached a text > file containing trigger and function code. > > Thanks for any insights you can provide. There's way too much logic going on there for me to test all the different cases. I suspect this is your problem: you triggered a case somehow which is not handled properly via your labyrinth of switches and loops. I highly doubt this is a case of database corruption. My advice here would be to not rely on procedural code to guard against something which can and should be enforced by a constraint. If something is wrong (source_id being null), declare it to be wrong -- that way the next time this happens the constraint will bounce the transaction and you can catch the problem when it happens as opposed to reverse engineering it. merlin
В списке pgsql-general по дате отправления: