Forum OpenACS Development: Re: Res: Re: Res: Duplicate keys on assessment - possible CR bug
This are great news, but this does not simplify release management. Interestingly enough, since OpenACS 5.3 seems to work under Oracle, i deduce that
db_dml lock_objects "LOCK TABLE acs_objects IN SHARE ROW EXCLUSIVE MODE"
works under oracle as well. I would think, that in oracle, this locking is not needed at all, and in the postgres case, we should only do this test if the following returns 1:
select 1 where substring(version() from 'PostgreSQL #"[0-9]+.[0-9+]#".%' for '#') < 8.2;
I would hate to do the version check on every insert operation. not sure, what the best approach for acs-content-repository is. On the xotcl-side, the newest version of xotcl-core creates now depending on postgres+version conditionally a locking rule; so there is no runtime penalty for version checking.
a) Require PG 8.2 or higher for OpenACS 5.4
b) For 5.3 keep the lock table statements in, or, alternatively, provide a parameter in acs-content-repository "OldPGP" which is turned on if upon installation (or upgrade) you find that the system is running on an Old DB version. Or store it in an nsv_array and check upon starting the AOLserver.
Interestingly I got problems with "lock table acs-objects in share row exclusive mode" on a farily busy site running against PG 8.2.3.
So, if someone experiences more deadlocks, a simple test case would be certainly helpful to nail this down.
We did test and everything is fine on this regard, now we have in production that.
I´m sure oracle did not have this silly deadlock.