I had a chance to look at this earlier than I thought I would. In postgresql a data-change violation is triggered when a column that is a foreign key is changed more than once in the course of a transaction. In your example, the update causes the cr_items_publish_update_tr to insert a new row into the cr_item_publish_audit table, and the content_revision__delete method will cause the corresponding row to be deleted from the same table. All during the course of the same transaction. This triggers the data-change violation.
So far the only work-around that I can think of that preserves the auditing functionality is to remove the foreign key constraints from all of the columns in the cr_item_publish_audit table. Doing this, you avoid the data-change violation, and you still retain the auditing information. This is not an ideal solution, but it's probably acceptable until we get a fix from the postgresql team.
