[email protected] wrote: > OK, I've found the problem, and it seems to be a configuration problem. > Please read below.
Great. Thanks for taking the time to look at this. > ^^^ An entry with the same DN exists in the superior database. As a > consequence, this entry is returned by back-bdb's tool functions, but > backglue tries to release it using back-perl. Since back-perl does not > have any tool functions, what is considered a safe replacement is used. > Unfortunately, the safe replacement doesn't know how to deal with > read-only entries returned by back-bdb. The solution consists in: > > - temporarily commenting the instance of back-perl > > - removing this entry from your back-bdb > > - re-enabling the instance of back-perl > > A follow-on to this ITS could be to devise a means to detect whether a > superior database contains entries that belong to a subordinate one, and > warn the administrator of the inconsistency. Ah I see. I remember thinking at the time whether or not I needed a DN within my master database too (similar to a FS mount point) but obviously it has been this that has been causing the problem. At least now I know that this isn't the case and can work around it. I'd expect a subordinate database to always override the master (similar to the mount point idea again) but in the case of slapcat then I believe it should probably just ignore a subordinate that doesn't have a physical backing store presence such as back-perl. I'm not sure quite how you'd mark this though. An appropriately worded warning would definitely be a good start, especially as when I first started working with back-perl as a subordinate, I was confused that putting the subordinate definition after the master would always fail whereas putting it before would allow it to work. ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs
