Bug applies only to posix super / superclassic.
Database file's ID is used on posix in order to better detect what file is used as database's primary and avoid use of same file as 2 different databases in case of hardlinks. So far so good but in a case when databases are often created/dropped ID plays bad game for us.
ID is also used in config resolution code in order to avoid use of different per-DB configs for same database. When database with particular ID (i.e. inode number) is dropped file is also deleted and inode may be reused. Therefore we may get another database with same ID, which currently causes invalid operation of config code.
Bug applies only to posix super / superclassic.
Database file's ID is used on posix in order to better detect what file is used as database's primary and avoid use of same file as 2 different databases in case of hardlinks. So far so good but in a case when databases are often created/dropped ID plays bad game for us.
ID is also used in config resolution code in order to avoid use of different per-DB configs for same database. When database with particular ID (i.e. inode number) is dropped file is also deleted and inode may be reused. Therefore we may get another database with same ID, which currently causes invalid operation of config code.