Forum OpenACS Q&A: Re: corrupt cr? How to audit cr_ tables?

Posted by Don Baccus on
Something's screwy...

create function cr_scheduled_release_tr () returns opaque as '

raise EXCEPTION ''-20000: Inserts are not allowed into cr_scheduled_release_job.'';

return new;
end;' language 'plpgsql';

create trigger cr_scheduled_release_tr
before insert on cr_scheduled_release_job
for each row execute procedure cr_scheduled_release_tr ();

This trigger exists because cr_scheduled_release_job is supposed to be a one-row table.

Other than the initial INSERT that follows the CREATE TABLE command when OpenACS is installed, there's only one UPDATE statement on the table in acs-content-repository.

It looks to me as though PG's making the old dead rows visible (UPDATE creates a new row, but transaction management is supposed to make the previous row invisible).

BTW deleting all the rows isn't probably the best thing to do, since the trigger will now prevent you from adding the one row the UPDATE wants to UPDATE :) You might drop the trigger, add the row, and recreate the trigger.

However ... there may be something wrong with your database that's a lot more important than this table.

If I were you, I'd dump the database, load it into a fresh db, and do some sanity checking to make sure you can dump and restore it ...

Posted by Tom Jackson on
Not related to the bug really, but scheduled procs should nearly always run in a thread. If any scheduled procs were supposed to run while this one was busy, they would be skipped. In addition, these skipped scheduled procs will not reschedule, so you lose all of them until a restart.