The DriverManager uses ftok() to generate a unique IPC key, and the file that is used as input to ftok() is the system odbc.ini file. However, it turns out ftok() uses the inode number of the file, which means that if the file is modified so that the inode number changes, the result of ftok() changes. Then a new IPC area will be created, and the old one is leaked, and eventually the system runs out of IPC resources unless manually cleaned up.
This is really a bug in ftok(), since the ftok() man page states that: "The resulting value is the same for all pathnames that name the same file, when the same value of proj_id is used.". This is not true, ftok() generates the same key if the inode is the same, not the path.
I suggest that the input to ftok() should be a file that normally won't be changed, or that some other mechanism is used to generate the unique key (a hash based on file name maybe?).
OK, not sure though if there is a simple fix. Normally odbc.ini will not change that often, but of course can and does, but any other file on the system could also change. Maybe the solution is to make it a build time choice defaulting to odbc.ini. AFAIK, few if anyone uses the stats now anyway as the gui to display them is generally not used.
Ok, I have added a configure option --with-stats-ftok-name to allow setting the file used to be something other than the default system odbc.ini
Wow, that was a lightning fast fix. :-)
Thanks!