Sad thing is, the word occasionally should imply that I can't reproduce the error conditions. It just happens without any trace of the why. Hitting reload works sometimes. Sometimes you end up with multiple revisions. Sometimes the item is there, but the revision is not.
But entering the same data as the same user 3 minutes later works perfectly fine.
One of my assumtions is that we might have a strange race condition when we have nested db_transactions. Example:
db_transaction {
invoice::edit
.... more stuff that needs execution ....
}
where invoice::edit has
db_transaction {
content::revision::new
.. more stuff that needs execution ...
}
content::revision::new again has
db_transaction {
if {[string equal "" $revision_id]} {
set revision_id [db_nextval "acs_object_id_seq"]
}
db_dml insert_revision $query_text
update_content -revision_id $revision_id -content $content
}
}
and at the query text it breaks. But as i said, I can't tell you why and when. And I am no guru with regards to postgres to be able to say what could trigger the db_dml statement to be executed twice, resulting in the error message of the unique constraint (or when could an insert also violate a unique constraint).
Nis, this is PG 8.0.6 we are talking about.
