---------------------------------------------------------------------- ELOQUENCE B.08.10 - patch PE81-1808230 ---------------------------------------------------------------------- This patch adds enhancements or fixes defects of the eloqdb server program as released with Eloquence B.08.10. This patch will be integrated in the Eloquence B.08.10 release. Eloquence B.08.10 must be installed before applying this patch. Severity: PE81-1808230: BUG FIX Superseded patches: PE81-1609130: BUG FIX PE81-1506230: BUG FIX PE81-1501300: BUG FIX PE81-1411100: BUG FIX PE81-1410010: BUG FIX PE81-1312160: BUG FIX PE81-1312040: BUG FIX PE81-1302270: BUG FIX PE81-1210040: BUG FIX, ENHANCEMENT PE81-1110210: BUG FIX PE81-1109290: BUG FIX PE81-1109210: BUG FIX PE81-1109020: BUG FIX PE81-1102250: BUG FIX PE81-1012200: BUG FIX PE81-1011110: BUG FIX Patch PE81-1808230 ------------------ Platforms: All * Fixed a regression introduced with patch PE81-1609130 which could cause the database server to crash due to a SIGILL signal, or to abort with a message like below: Assertion failed: (int)rwlock->readers >= 0 server panic: Aborting on internal failure, file thread.c, line 2107 * Fixed a problem where repeating an interrupted startup recovery could result in an empty forward-log "bridge" segment (#4255). After an abnormal termination, the database server (or the dblogreset utility) perform a startup recovery. During this process, a special forward-log "bridge" segment is created that allows a dbrecover, dbrepl or fwutil process to continue across the previous abnormal termination. Interrupting and then repeating the startup recovery should resume on an existing "bridge" segment. However, because an internal state was not correctly initialized, the resulting "bridge" segment could be empty. Notes / Related patches: * Patch PE81-1808231 or superseding (dblogreset utility) should be installed with this patch. Patch PE81-1609130 ------------------ Platforms: All * Fixed a problem where write operations could be stalled while on-line backup mode is stopped (#4228). If stopping on-line backup mode takes some time so that a checkpoint operation is started, an internal lock could cause concurrent write operations to block until on-line backup mode has stopped. This problem was introduced with patch PE81-1312040 (#4128). * Fixed a problem where in a rare case a newly created database could get (partially) lost if the database is created while on-line backup mode is active and afterwards the database server is restarted while still in on-line backup mode (#4224). * Fixed a minor problem when adding/deleting records in a data set and shortly afterwards stopping the database server before a checkpoint operation has been performed (#4225). In this case, the next time a new record is added to that data set, the database server has to skip redundant entries in the list of free record numbers. These records would also be warned about if the dbfsck utility is run with -vvv verbosity. * Fixed a potential buffer overflow in the http status. * Enhance thread status to provide additional information when a thread is blocked on a mutex lock. Patch PE81-1506230 ------------------ Platforms: All * A problem was fixed which could cause the database server to abort during database restructuring with an internal error (#4211). A message as below was logged: server panic: Fatal problem detected in cv_zoned Assertion failed: rc >= 0 server panic: Aborting on internal failure, file restruct_set.c This problem was caused by corrupted P or Z item values that could in some cases result in an unexpected conversion error. The database restructure process was changed to no longer fail due to corrupted item values. When a corrupted value is encountered the item is set to a default value (zero for numeric items). A message is written to the log for every item a conversion problem was encountered. WARNING: corrupted value during size conversion (item 'SET.ITEM') WARNING: precision loss during size conversion (item 'SET.ITEM') data set 'SET' has been restructured (### records) NOTE: ### conversion problem(s) encountered Patch PE81-1501300 ------------------ Platforms: All * A problem was fixed which could cause a slave server to not resume replication if the master server was shut down while on-line backup mode was active and the following on-line backup recovery was aborted (#4186). After the eloqdb is shut down while on-line backup mode is active, the eloqdb (or the dblogreset utility) performs a recovery from on-line backup mode. This may take considerable time, depending on the amount of data redirected to the log volume while on-line backup mode was active. Interrupting and then repeating this recovery could result in a wrong volume generation count, causing a slave server to stop replication. * Improved the interoperability of the dbrecover utility with database replication (#4201). After using the dbrecover utility on a replication master server, the resulting database environment can be used to synchronize a slave server, regardless whether dbrecover completely processed the last forward-log generation or a point-in-time recovery was performed where the last forward-log generation was processed only partially. If a master or slave server detects a previous point-in-time recovery, the volume generation count is incremented and a message like below is logged: L0: Note: dbrecover point-in-time recovery detected, volume generation set to ... Please note: It is not supported to use the dbrecover utility on a slave server to perform a point-in-time recovery, then later resume replication. Doing so would very likely result in slave server data corruption and/or would cause the slave server to crash. Notes / Related patches: * Patch PE82-1501301 or superseding (dblogreset utility) should be installed with this patch. Patch PE81-1411100 ------------------ Platforms: Windows * Fixed a potential event handle leak when a database session is closed (#4196). * Fixed misleading LogFile output on the config page of the HTTP status display if LogFile is set to syslog (#4197). Patch PE81-1410010 ------------------ Platforms: All * Fixed a potential race condition where under rare conditions dbopen could succeed although the database was already opened exclusively by another session purging the same database (#4188). As a consequence, the eloqdb server process could abort on a failed database consistency check because the database was accessed while being purged, for example: server panic: Fatal problem detected in Node_Delete Assertion failed: !node->ref_count server panic: Fatal problem detected in Pool_ReadAcc Assertion failed: Pool_TestFlag(Pool_BLOCKUSED, &header) server panic: Fatal problem detected in FixRec_GetLock Assertion failed: node * Fixed a potential race condition where under rare conditions accessing a database on a replicated slave server was not sufficiently locked against a concurrently replicated dbpurge or dbctl dbrestore (#4188). As a consequence, the eloqdb server process could abort on a failed database consistency check, for example: server panic: Fatal problem detected in FixRec_GetClusterAddress Assertion failed: meta->ulist_cache server panic: Fatal problem detected in Pool_ReadAcc Assertion failed: Pool_TestFlag(Pool_BLOCKUSED, &header) * Shutting down the eloqdb server process could in some cases result in messages as below (#3623): epoll_ctl: write failed. [9] Bad file number This could happen if worker threads terminate after the internal event thread. The messages are harmless and have no further implications. * Fixed a potential race condition where a new forward-log generation could start with pending information from the previous segment (#4047). This could unexpectedly require that the previous segment is present when a recovery or replication is started. Patch PE81-1312160 ------------------ Platforms: HP-UX * Fix a potential performance regression on HP-UX introduced with "vnode" locking changes in patch PE81-1312040. Patch PE81-1312040 ------------------ Platforms: All * Fixed a lock starvation issue that could happen under a specific workload. This might cause eloqdb threads to be blocked for an undefined period waiting on the internal "vnode" lock. This should only affect large systems under high load. * Improved scalability of the internal "vnode" lock. The internal "vnode" lock could impact performance and CPU consumption under some workloads if the vnode lock is contended. * Fixed a rare problem where a data block in the volume files might get corrupted when the eloqdb process aborts performing a checkpoint operation while stopping on-line backup mode (#4128). * A replication slave server may not increment the volume generation after dbrecover (#4129). The eloqdb server increments the volume generation twice when started after a previous dbrecover. However this is not allowed on a slave server as this causes a forward-log generation to be missed. Patch PE81-1302270 ------------------ Platforms: All * Fixed a problem where in a rare case a data block in the volume files might get corrupted when on-line backup mode is stopped (#4108). Depending on the database activity, operating system load and I/O activity a disk write might get reordered while on-line backup mode is stopped. This could result in stale data written to the data volume. * Fixed a possible transaction journal corruption if the database server was stopped (or aborted) while in on-line backup mode after using the dblogreset or dbrecover utility (#4126). The database server process might allocate the transaction journal in an improper mode if the dbrecover or dblogreset utility was used before starting the server process. If the server is subsequently shut down (or aborted) while in on-line backup mode the volume recovery might fail. * Fixed a problem where under certain conditions a dbutil DELETE SET / CREATE SET sequence could result in a broken chain (#4116). If a data set was deleted and then recreated in the same dbutil invocation the chain pointers were not correctly initialized in some cases. * Fixed a problem where a DBGET mode 6 could miss one record after a TurboIMAGE TPI DBFIND on a master set using a less-or-equal condition. * Modified the database server startup behavior in case a transaction journal corruption is detected. If the database server aborts unexpectedly due to a power failure or an operating system problem and the SyncMode configuration has been deactivated, it might happen in rare cases that the transaction journal is damaged so that on startup the database server cannot perform its usual transaction recovery. In such a case, the database server now aborts immediately with a message like below, preventing the problem to remain unnoticed: "WARNING: Unable to perform volume recovery due to inconsistencies. Please restore the data volume files from a backup, then use dbrecover to apply the forward-log. If this is not possible, use dblogreset to manually perform a volume recovery, then check the data volume with dbfsck." Patch PE81-1210040 ------------------ Platforms: All * Fixed a problem where under rare conditions the HTTP thread could terminate unexpectedly on a failed network call (#4094). A message like below would be logged: X0: [7] getsockname failed. [22] Invalid argument D0: [7] Unable to obtain local address - dropping connection As a consequence, the HTTP status did no longer respond. Also, this could cause new connections to hang because an unexpected thread id was used. * Fixed a problem where the database server process could abort during startup with a message like below (#4110): Assertion failed: node server panic: Aborting on internal failure, file nodecore.c, line 1437 A forward-log record was wrongly initialized under some rare conditions. * Fixed a problem where a dbutil UPGRADE DATABASE command could cause the database server process to abort with a message like below (#4098): Assertion failed: col->colid > unique server panic: Aborting on internal failure, file syscat.c, line 4393 This could happen if UPGRADE DATABASE was applied to a database where the items were reordered alphabetically so that the column identifiers were no longer incremental. * Fixed potential performance issue on TurboIMAGE DBFIND modes 1/21 on index items (#4101). An index search on key arguments containing the * or [ characters could be inefficient in certain cases due to internal wildcard masking rules. * Fixed a potential compatibility problem with dbstore archives that were created with newer database server versions (#4073). * Improved the database compatibility checks on DBOPEN (#4073). * Added diagnostic messages on internal log record hash inconsistency (#4068). Patch PE81-1110210 ------------------ Platforms: All * Fixed a problem where under rare conditions the database server could abort due to a segment violation if multiple dbctl list invocations were issued at the same time (#4065). Patch PE81-1109290 ------------------ Platforms: All * The dbctl list session and dbopen commands as well as the HTTP status session and database lists could in rare cases cause the database server to abort due to a segment violation (#4063). This was caused by an internal race condition where a session was accessed that was just closing a database. Patch PE81-1109210 ------------------ Platforms: All * The dbctl list db and dbopen commands as well as the HTTP status database list could in rare cases cause the database server to abort due to a segment violation (#4062). This was caused by an internal race condition where a session was accessed that was just shutting down. Patch PE81-1109020 ------------------ Platforms: All * Fixed a problem that could result in a database server hang due to an internal deadlock under rare conditions (#4059). If a data volume runs out of space while on-line backup mode is active, a transaction record is written to the log volume to postpone the data volume extension until on-line backup mode is stopped. Under rare conditions, writing this transaction record could overlap with a concurrent checkpoint operation in a way that an internal deadlock could occur. Patch PE81-1102250 ------------------ Platforms: All * Fixed a corner case incompatibility with TurboIMAGE (#4024). In TurboIMAGE a failed DBFIND call does not change the current chain. This behavior change does not apply to programs written in the Eloquence language. This change is only effective if this patch and the related client library patch PE81-1102251 (or newer) are installed. Patch PE81-1012200 ------------------ Platforms: All * Fixed a problem where in a rare corner case the database server process could abort with a message like below (#3781): Assertion failed: !node->ref_count server panic: Aborting on internal failure, file nodecore.c, line 388 This was caused by an internal race condition between client session termination and a concurrent dbpurge operation on one of the involved databases. Patch PE81-1011110 ------------------ Platforms: All * Fixed a problem that could result in a server panic when deleting a record. The following message is written to the server message log: Assertion failed: set_ctx->idx_mode == IS_INVAL This can happen under the following conditions: 1. The database is accessed from the Eloquence language 2. The database client cache is enabled 3. Some records were read (eg. sequential) but additional records are in cache 4. A DBFIND on an index item in the same data set is called 5. A DBELETE is called to delete the record In this case the current record differs between the client and server side and nees to be re-established. However, a DBDELETE did not expect a previous index lookup in this case. Installation: ------------- Please download the patch archive that corresponds with the installed release. The patch files follow the conventions below: PE81-1808230-hpux-ia64.tar.gz ^ ^ ^ | | Architecture / OS specific build | Operating system Patch ID HP-UX: In order to install this patch, you need to unpack it with gzip and tar. Gzip is included with HP-UX. Installation requires root privileges. cd /opt/eloquence/8.1 gzip -dc /path/to/PE81-1808230-hpux.tar.gz | tar xf - Files: bin/eloqdb32 (32 bit database server) bin/eloqdb64 (64 bit database server, not available on hpux-pa11) share/doc/PE81-1808230-README Linux: In order to install this patch, you need to unpack it with tar. Installation requires root privileges. cd /opt/eloquence/8.1 tar xzf /path/to/PE81-1808230-linux.tar.gz Files: bin/eloqdb32 (32 bit database server, only available on linux-i686) bin/eloqdb64 (64 bit database server, not available on linux-i686) share/doc/PE81-1808230-README Windows: Two options are available for patch installation. The patch is available as self extracting archive for automatic installation and as a zip archive for manual installation. Both patches are equivalent. Installation requires administrative capabilities. For automatic installation of this patch, please download the patch file PE81-1808230-win32.exe. Before installation, please consider stopping the database server, then execute the patch installation program. Installation does not require a reboot unless the patched files were active. For a manual installation of the patch, please download the patch file PE81-1808230-win32.zip and unpack its contents. Then perform the following steps: * Please make sure the eloqdb service is stopped before installing the patch (in the Service Control Manager or with net stop eloqdb). * Please copy the eloqdb32.exe and eloqdb64.exe files into the Eloquence bin directory. (Default location: C:\Program Files\Eloquence\8.1\bin) * Please copy the PE81-1808230-README.txt file into the Eloquence share\doc directory. (Default location: C:\Program Files\Eloquence\8.1\share\doc) Files: eloqdb32.exe (32 bit database server) eloqdb64.exe (64 bit database server) PE81-1808230-README.txt