There is a small but critical risk in incremental tranlogging of NSCs, which implement IdentityBags and subclasses of IdentityBag. Changes in collections that are kinds of IdentityBag may not record entries in the transaction logs for one or more slots. When the tranlogs are later replayed, as part of a recovery after shutdown, a hot standby, or restore into another system, the resulting restored system will be corrupt: the collection would have nils in slots that should contain valid objects.
Incremental tranlogging for collections involves writing only the changes to the objects to the tranlogs, rather than the complete object, and was done to avoid bloat. Incremental tranlogging was always done in older releases. In v3.6.1 and 3.5.6, the configuration parameter STN_TRAN_INCREMENTAL_LOGGING was added to allow control over incremental tranlogging.
To avoid issues, set STN_TRAN_INCREMENTAL_LOGGING to false in versions 3.5.6, 3.5.7, or 3.6.1. If you are using an older version (before STN_TRAN_INCREMENTAL_LOGGING was available), upgrade is recommended. This bug is not present in versions earlier than 3.4.
Last updated: 2/8/24