----------------------------------------------------------------------
ELOQUENCE B.08.00 - patch PE80-1302270
----------------------------------------------------------------------
This patch adds enhancements or fixes defects of the eloqdb server
program as released with Eloquence B.08.00. This patch will be
integrated in the Eloquence B.08.00 release.
Eloquence B.08.00 must be installed before applying this patch.
Severity:
PE80-1302270: BUG FIX
Superseded patches:
PE80-1210040: BUG FIX
PE80-1202020: BUG FIX, ENHANCEMENT
PE80-1110210: BUG FIX
PE80-1109290: BUG FIX
PE80-1109210: BUG FIX
PE80-1109020: BUG FIX
PE80-1012200: BUG FIX
PE80-1005250: BUG FIX, ENHANCEMENT
PE80-1002230: BUG FIX
PE80-1001190: BUG FIX, ENHANCEMENT
PE80-0912280: BUG FIX
PE80-0911090: BUG FIX
PE80-0909220: BUG FIX
PE80-0907030: BUG FIX
PE80-0906080: BUG FIX, ENHANCEMENT
PE80-0905130: BUG FIX
PE80-0904270: BUG FIX
PE80-0904240: BUG FIX
PE80-0904060: BUG FIX
PE80-0903270: BUG FIX
PE80-0903060: BUG FIX
PE80-0903040: BUG FIX
PE80-0902091: ENHANCEMENT
PE80-0901090: BUG FIX
PE80-0812180: BUG FIX
Patch PE80-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 PE80-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.
Patch PE80-1202020
------------------
Platforms: All
* 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 internal log record diagnostics (#4068).
Patch PE80-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 PE80-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 PE80-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 PE80-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 PE80-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 386
This was caused by an internal race condition between client
session termination and a concurrent dbpurge operation on one
of the involved databases.
* 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.
Platforms: Windows
* Fixed a problem on the Windows platform related to HTTP status
timeout introduced with patch PE80-1005250.
Patch PE80-1005250
------------------
Platforms: All
* The HTTP status was fixed to correctly support a timeout.
* The HTTP status was enhanced to display additional information
on the installed license in the config web page.
* The server was enhanced to implicitly grant a DBA user
administrative capabilities on a database. Previous versions by
default granted administrative capabilities only to the account
that was used to create the database.
As a consequence, the following behavior is changed: Any user
with DBA privileges may
- purge or erase any database
- dbstore or dbrestore any database
- perform a dbdumpcat on any database
- change the database structure
- change the database access rights
Please note that some of these functions are only available with
an updated dbutil version.
With previous server versions only the user that created a
database (or was granted administrative capabilities subsequently)
was able to perform these tasks. Other users, even with DBA
privileges would fail.
* The DBUPDATE mode 2 on a master set was changed to return
status 43:0 instead of -804:0 when a duplicate key item value
is specified.
* Fixed a problem where in rare cases the a status -700:-3 was
returned when establishing a connection to the db server.
This was caused by a race condition when sessions connect and
disconnect concurrently. In rare cases it could happen that
queued events for a disconnected server connection were
attributed to a new connection. This could have the effect
that the db server terminated a session that was just started.
Please notice there are a number of other causes for a
status -700:-3 (such as lack of kernel or db server resources).
Platforms: Linux
* Fixed a problem with dbctl killthread not terminating an idle
thread.
Patch PE80-1002230
------------------
Platforms: All
* Fixed a problem where in rare cases the database server process could
abort with a message like below (#3948):
Assertion failed: tcp->wchan_type == Wait_OTHER && !tcp->wchan.ptr
server panic: Aborting on internal failure, file thread.c, line 4813
This was caused by a race condition where a thread status was tested
without obtaining the required lock. In rare cases it could happen
the thread status changed unexpectedly.
Patch PE80-1001190
------------------
Platforms: All
* The dbctl list session and dbctl list dbopen commands could in rare
cases cause the database server to abort with a message like below
if a filter condition was used (#3929):
Assertion failed: audit
server panic: Aborting on internal failure, file ssn_util.c, line 1245
This was caused by an internal race condition where a session was
accessed that was just shutting down.
* Improved the database compatibility checks on DBOPEN (#3930).
* Improved the compatibility with dbstore archives that were created
from databases that were previously recovered or replicated (#3921).
Patch PE80-0912280
------------------
Platforms: All
* Fixed a problem where in rare cases the buffer cache failed to write
a page modification to disk due to an internal race condition, resulting
in an incorrect free-list page link/pointer (#3853).
This caused the database server to abort subsequently with a message like
below:
Assertion failed: freelist_miss == 0
server panic: Aborting on internal failure, file volfrec.c, line 1065
When encountering this issue the dbfsck utility may be used to correct
the damaged free-record lists. It is recommended to use the dbfsck version
from patch PE80-0912040 (or newer).
* A database restructuring could temporarily require significantly more
available disk space in the data volume(s), as compared to Eloquence
B.07.10 (#3908).
While restructuring a data set, a lock was held that could block the
checkpoint thread. If the checkpoint thread is blocked, temporarily
occupied space in the data volume is not timely released.
* Performing a replication or recovery after an abort of the database
server process could in rare cases lead to inconsistent data set meta
information (#3909).
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.
Replicating this bridge segment, or using it with dbrecover, could
in rare cases incompletely update the data set meta information.
* The dbctl list dbopen command could in rare cases cause the database
server to abort due to a segment violation. This was caused by an
internal race condition where a session was accessed that was just
shutting down.
* Fixed a race condition that could cause a corrupted disconnection log
message output to the server message log (#3858).
Patch PE80-0911090
------------------
Platforms: All
* An internal counter overflow could cause the database server to
abort in rare cases with a message like below (#3875):
Assertion failed: unexpected recursive lock
server panic: Aborting on internal failure, file thread.c, line 1490
An internal 32-bit variable is incremented on every committed
transaction and may therefore overflow after ~4 billion commit
operations. This overflow is handled but could cause an unexpected
side effect.
* Searching an index could cause the database server to abort in rare
cases with one of the below messages or a segmentation fault
condition (#3879, #3880):
Assertion failed: tmp_bhp->id.node_id == node_id
server panic: Aborting on internal failure, file mpool.c, line 972
Assertion failed: bhp != NULL
server panic: Aborting on internal failure, file mpool.c, line 2582
While an index is searched, a concurrently committed transaction
may invalidate the index tree and the search operation must be
restarted. In some rare cases, this conflict was detected too late
and the search was continued although the index tree was invalidated
in the meantime. As a consequence, index pages that did not have
the expected state or no longer belonged to the index could be
read. If this was detected, data corruption was assumed and a
server panic was issued. If not, accessing the page contents
caused a segmentation fault.
* A dbutil CHANGE IITEM operation did not rebuild the associated
indexes if only the offset into an item was changed for an index
segment (#3884).
As a consequence, the index data did not correspond to the index
specification in the database schema.
The index could be manually rebuilt to solve this problem. For
example, the dbutil script below rebuilds the index associated
with the IMATCHCODE index item in the CUSTOMERS data set:
CHANGE SET CUSTOMERS {
DELETE INDEX IMATCHCODE;
ADD INDEX IMATCHCODE;
}
To enforce rebuilding an index, delete it from the data set and
then add it again in the same dbutil script.
* When a dbutil ADD ITEM data set clause is used to add an item
of type P (packed) to a data set, the subsequent restructuring
process now initializes this new P item to unsigned zero (#3857).
Previously, a new P item was initialized to binary zero.
* After a dbutil RENAME DATABASE operation, the audit information
in the forward-log was not updated until a new forward-log file
was started (#3868).
In the database audit, the renamed database remained visible
under its previous name until the end of the current forward-log
file.
* If a transaction was committed after a related database was closed,
it could happen in rare cases that the associated audit information
was not written to the forward-log (#3869).
In such a case, the affected actions did not appear in the database
audit.
* A forward-log bridge segment was not correctly restarted (#3883).
After an abnormal termination, the database server (or dblogreset)
performs a startup recovery. During this process, a so called
forward-log bridge segment is created that allows a dbrecover or
dbrepl or fwutil process to continue across the previous abnormal
termination.
If for any reason the startup recovery is aborted so that the
bridge segment is not completely created, the bridge segment should
be restarted and completed on the next startup recovery.
Due to an internal initialization problem, this did not work as
intended. As a consequence, the database server (or dblogreset)
failed to start with a message like below if the bridge segment
already exists:
unable to create forward-log ... File exists (errno 17)
Note: failed to restart forward-logging
To solve this problem, the existing bridge segment must be manually
deleted before starting the database server or dblogreset.
* An internal race condition could cause an unexpected time stamp
information in the database server log file.
If log entries were written simultaneously by concurrent threads,
a wrong time stamp information could be output.
* When reporting a server panic, the database server often issued
another server panic caused by a segmentation fault condition.
This is now suppressed.
Also, in case of a server panic the IPC semaphore resources were
not properly cleaned up.
Patch PE80-0909220
------------------
Platforms: All
* Fixed a problem which in a rare corner case could cause a database
server to abort with a message like below (#3852):
Assertion failed: tx_data_prev.op == BT_TX_NewPage || tx_data_prev.op == BT_TX_UpdPage
server panic: Aborting on internal failure, file btree.c, line 1089
This was a transient problem, caused by an internal race condition,
and had no impact on the database, except that the database server
had to be restarted.
Patch PE80-0907030
------------------
Platforms: All
* Fixed a potential memory leak when using multiple consecutive
wildcard characters in a DBFIND argument (#3794).
* Fixed a problem with DBFIND wildcard arguments where a "?*"
sequence was evaluated as a single '*' wildcard character (#3794).
Patch PE80-0906080
------------------
Platforms: All
* Fixed a potential memory leak when a dbctl list output exceeded
the size of the shared memory communications buffer (#3785).
* The dbctl list command was enhanced. A filter expression may be
specified and the /count option may be used to only obtain the
number of matching entries.
For example:
$ dbctl list session "pname=*query3k*"
$ dbctl list lock /count "status=blocked"
Please refer to the dbctl documentation for details:
http://eloquence.marxmeier.com/support/B0800/doc/dbctl/index.html#list
Patch PE80-0905130
------------------
Platforms: All
* Fixed a problem which could cause the database server to temporarily
hang while on-line backup mode was shutting down (#3782).
If a checkpoint operation overlapped with stopping on-line backup
mode, the checkpoint could block and in turn block any existing or
new database sessions until on-line backup mode was shut down.
Patch PE80-0904270
------------------
Platforms: All
* This patch corrects a problem introduced with fix #3777 delivered
with the previous patch PE71-0904240.
Patch PE80-0904240
------------------
Platforms: All
* The dbctl forwardlog restart command did not immediately update the
volume generation count in the log volume (#3777).
As a possible consequence, the database server could fail to start
with a message like below if it was abnormally terminated after a
dbctl forwardlog restart was issued:
failed to open volume: volume ... has inconsistent generation count
As a workaround it is possible to manually update the generation
count in the log volume in this case. Please contact support if you
are affected by this.
Patch PE80-0904060
------------------
Platforms: All
* Fixed a problem where a database was not immediately available
after a dbutil restructuring (#3751). A subsequent DBOPEN executed
immediately after a restructuring dbutil process had finished could
in some cases encounter a database status -2 (database in use).
* Resuming a replication or recovery could in rare cases abort with
a message like below (#3752):
Assertion failed: Fwr_PageHashAdd() failed: key already present
server panic: Aborting on internal failure, file volfwr.c, line 5367
This could happen in a corner case if a user transaction spans
multiple forward-log files, where BTREE PAGE actions are present
in different files at identical offsets. Under these conditions
the problem could be triggered if these files had to be processed
to locate the last status of the replication progress.
* Resuming a replication or recovery could in rare cases abort with
a message like below (#3755):
recovery failed ... node ... page ... not in expected state
Assertion failed: h->lower == data->lower
server panic: Aborting on internal failure, file btree.c, line 2382
This could happen in a corner case if a user transaction spans
multiple forward-log files, where the transaction was executed
immediately after the last status of the replication progress
was found and the replication was resumed.
Patch PE80-0903270
------------------
Platforms: All
* Under certain conditions the database server could hang due to an
internal deadlock (#3739).
In rare cases under high load, if a deadlock was detected between
two tasks so that one of these tasks was signaled, and at the same
time another task detected the same conflict as the task being
signaled, a deadlock could occur. As a consequence, the database
server did no longer accept new connections and could not be shut
down but had to be killed.
* In rare cases under high load, the database server could abort with
a message like below (#3741):
Assertion failed: current_task->waiting_for == NULL
server panic: Aborting on internal failure, file thread.c, line 2837
If a deadlock was detected between two tasks so that one of these
tasks was signaled, the task being signaled could in some cases
remain connected to the conflicting task. This could then cause the
problem to occur due to an out-of-context notification.
* A race condition was fixed that could cause a DBPUT or DBUPDATE
operation to fail with a -809/1024 status (#3742).
During a DBPUT or DBUPDATE executed simultaneously with a DBDELETE,
the database server could temporarily encounter an inconsistent
state of an automatic master chain head, where the master key was
found in the index while the corresponding master record did no
longer exist.
* A race condition was fixed that could cause a wrong date/time
prefix being written to the database server log file (#3731).
Patch PE80-0903060
------------------
Platforms: All
* An internal memory leak was fixed (#3708). Some memory was not
correctly released when a new connection was established.
This may eventually result in memory allocation failures that
require a re-start of the database server process.
Patch PE80-0903040
------------------
Platforms: All
* A dbutil RENAME DATABASE operation could cause the database
server to abort with a message like below (#3704):
Assertion failed: SysCat_LinkAddrEquals ...
server panic: Aborting on internal failure, file syscat.c, line 1943
* An internal memory leak was fixed (#3708). Some memory was not
correctly released when closing a connection. This may eventually
result in memory allocation failures in the database server process
that require a re-start of the server process.
* In rare cases, a malformed client request or an incomplete tcp/ip
network packet could cause the database server to abort with a
message like below (#3705):
Assertion failed: size != 0
server panic: Aborting on internal failure, file buffer.c, line 777
Patch PE80-0902091
------------------
Platforms: All
* This patch enables dbutil to change item order (#3689).
Notes / Related patches:
- dbutil patch PE80-0902090 (or superseding) supports changing
item order.
Patch PE80-0901090
------------------
Platforms: All
* Fixed an internal race condition that could cause a database
server abort in rare cases when concurrently disconnecting
multiple database sessions (#3696). A message like below is
output to the log file:
Assertion failed: thread_rwlock_destroy failed
server panic: Aborting on internal failure, file thread.c, line 1815
The stack trace shows the following call stack:
(1) thread_rwlock_destroy
(2) Node_DeleteNodeMempageIfEmpty
(3) Node_Delete
(4) Tlog_Destroy
(5) idb_exit_session
* The dbctl forwardlog status command no longer requires dba
privileges.
Patch PE80-0812180
------------------
Platforms: All
* During an automatic forward-log file switch it could happen in rare
cases that transactions were not written to the forward-log (#3694).
As a consequence, a recovery or replication from this forward-log
would fail, for example with a message like below:
recovery failed in action ... page ... not in expected state
server panic: Fatal problem detected in btree_FWR__verify_page
Assertion failed: h->lower == data->lower
* A DBGET mode 6 or 16 on an index item could improperly return an
end-of-chain condition when the last key in the index was deleted
(#3683).
Installation:
-------------
Please download the patch archive that corresponds with the installed
release. The patch files follow the conventions below:
PE80-1302270-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.0
gzip -dc /path/to/PE80-1302270-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/PE80-1302270-README
Linux:
In order to install this patch, you need to unpack it with tar.
Installation requires root privileges.
cd /opt/eloquence/8.0
tar xzf /path/to/PE80-1302270-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/PE80-1302270-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 PE80-1302270-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 PE80-1302270-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.0\bin)
* Please copy the PE80-1302270-README.txt file into the Eloquence
share\doc directory.
(Default location: C:\Program Files\Eloquence\8.0\share\doc)
Files:
eloqdb32.exe (32 bit database server)
eloqdb64.exe (64 bit database server)
PE80-1302270-README.txt