> > Below is a significantly simplified version of my schema, which
> > exhibits
> > the above problem.
>
> Unfortunately, even a simplified version of your schema would take me
> some hours to understand. As your rule-setting is quite complex, my
> first instinct would be to hunt for circular procedural logic in your
> rules. Try to pursue, step by step, everything that happens from the
> moment you send the insert command to uservotes. You may find that the
> logic cascades back to the beginning. I've done this to myself on
> occasion, causing the DB to hang on a seemingly simple request.
I'm fairly certain that there's no circular procedural logic.
The errors can be turned on/off by turning on/off the uservote_ series
of rules, which are attached to the uservote table. These rules call
mod_node_vote_count which only touches the node table. There are no
rules or triggers associated with the node table, so there is no circular
logic there.
Additional strangeness is that the itemvote_ series of rules works perfectly
despite the fact that the only difference between uservote_ and itemvote_
rules is the table that triggers them, they both call the same procedure on
the nodes table.
My current thinking is that something is stomping on some memory, because
you can vary the effect of the error from being an incorrectly failed CHECK
constraint, to crashing the database, by varying the number of columns in
the tables in question.
I'm unemployed at the moment and this is a pet project, so I can't offer
much in the way of financial compensation, but I'll start the bidding at
$50 donation in your name to your choice of the EFF, the Red Cross, or the
American Cancer Society, in return for a fix. (If none of these charities
are acceptable, surely one can be found later that is acceptable to both
parties).
Again, I greatly appreciate any help, and I apologize that my test case is
still fairly sizeable, despite being about 10% the size of the original
code.
-Kevin Way
