----------------------------------------------------------------------
HP ELOQUENCE A.06.20 - patch 0009080
----------------------------------------------------------------------
This patch fixes a defect of the eloqdb6 program as released
with A.06.20. This patch will be integrated in a subsequent
HP Eloquence release.
A.06.20 must be installed before applying this patch.
This patch replaces patches PE62-9902110, PE62-9902170, PE62-9902221,
PE62-9902222, PE62-9903080, PE62-9903290, PE62-9903311, PE62-9904060,
PE62-9904120, PE62-9905250, PE62-9906100 (beta), PE62-9908310 (beta),
PE62-9909020 (beta), PE62-9911300 (beta), PE62-0001060 (beta),
PE62-0003040 (beta), PE62-0003280 (beta) and PE62-0006020.
Fixed problems:
---------------
Platforms: All
* A problem related to stopping online backup mode was solved.
Depending on database usage during online backup this could result
in data corruption when stopping online backup mode.
When the HP Eloquence database is in online backup mode committed
transactions are saved in the log volume not the data volume(s).
When the online backup mode is stopped (through dbctl backup stop)
committed transactions are transferred from the log volume to the
data volume(s). This could cause an extension of the data volume.
A volume extension while transferring committed transactions from
the log volume to the data volume could cause corruption of
information in the log volume.
Symptoms:
- server panic after stopping online backup mode
- dbfsck reports volume corruption
* Under rare circumstances a volume crash recovery could corrupt the
data volumes. This can happen when the eloqdb6 server has crashed
or was terminated with kill -9. In this case all committed
transactions since the last checkpoint operation are recovered
from the log volume during eloqdb6 startup.
A problem was found if a data area affected by a transaction was
deleted by a subsequent transaction and has been re-used since
the last checkpoint operation. In some cases this could lead to
corruption of structural volume information. This has been fixed by
delaying page re-use until the next checkpoint operation.
Symptoms:
- server panic during volume crash recovery
* When an eloqdb6 server panic (internal error) is encountered the
eloqdb6 process restarts itself by default. This can be configured
in the eloqdb6.cfg configuration file with the panic= configuration
item.
When eloqdb6 encounters a fatal problem during startup this will
cause eloqdb6 to be started in an endless loop, possibly filling
the log file and using system resources. Now eloqdb6 will not restart
automatically if a problem during restart is encountered.
Patch PE62-0006020
------------------
Platforms: All
* A problem related to rollback of subtransactions was solved.
Depending on database usage this could result in btree corruption
or an eloqdb6 server panic.
When a subtransaction was rolled back but the main transaction
continued it could happen that invalidated btree information
remained in memory and was used by subsequent btree operations.
This problem could only happen when using transactions.
Symptoms:
- Assertion failed: f_bhp->id.node_id == node_id
server panic: Aborting on internal failure, file mpool.c, line 392
- DBPUT failed due to duplicate secondary index
- dbfsck reports corrupted btree pages
Impact:
A database which shows the symptoms above must be reloaded (dbexport,
dberase and dbimport). Information besides internal btree is not
affected.
* The eloqdb6 server could panic during processing volume recovery
complaining about a buffer leak. This was caused by a bug
processing defective recovery information from the log volume.
* Cache buffer management has been tuned to provide better performance
for delete and update operations in a transaction. This should also
improve the impact of transactions on concurrent read operations.
Patch PE62-0003280
------------------
Platforms: All
* The previous patch PE62-0003040 incorporated a side effect which
could lead to a subsequent eloqdb6 panic:
Assertion failed: Fpool_Next(): Inconsistent anchor
server panic: Aborting on internal failure, file volpool.c, line 1351
Patch PE62-0003040
------------------
Platforms: All
* eloqdb6 could panic during volume recovery if transaction log meta
information is damaged. Volume recovery should not rely on the
consistency of meta information.
Assertion failed: iter->anch->last_block.offset == iter->addr.offset
server panic: Aborting on internal failure, file volpool.c, line 1313
Patch PE62-0001060
------------------
Platforms: All
* Under rare conditions 16 bit integer key values were incorrectly
inserted into an index. This could result in a subsequent database
status -96 (bad link to master set).
* The HTTP status display could show garbaged server configuration.
Patch PE62-9911300
------------------
Platforms: All
* A deadlock condition could occur during DBPUT and DBUPDATE in rare
cases causing the affected tasks to hang infinitely.
The solution to this problem implemented with PE62-9909020 had an
impact on concurrent read operations which became unnecessarily slow.
The current solution serializes write operations while read
operations are not affected. This should solve the performance
impact.
Patch PE62-9909020
------------------
Platforms: All
* A deadlock condition could occur during DBPUT and DBUPDATE in rare
cases causing the affected tasks to hang infinitely.
This was not completely solved with patch PE62-9908310.
Patch PE62-9908310
------------------
Platforms: All
* A deadlock condition could occur during DBPUT and DBUPDATE in rare
cases causing the affected tasks to hang infinitely.
Patch PE62-9906100
------------------
Platforms: All
* A zero record number in the free record list causes a panic in
Node_RemoveFirstItem() during DBPUT. This patch takes care of
a possible side effect when encountering the zero record
number.
Assertion failed: freelist_miss == 0
server panic: Aborting on internal failure, file volfrec.c, line 861
The zero record number is placed into the record free list during
pre-commit phase of a DBDELETE operation to ensure that the free list
does not need to be expanded during the final commit phase.
There was a small window of opporunity that a concurrent DBPUT
would request a new record number and could get that reserved
entry. This situation was not expected and the server paniced.
* The buffer allocation strategy in the buffer cache has been slightly
modified to handle cases of committing large transactions with
a small buffer cache configurtion more gracefully.
Patch PE62-9905250
------------------
Platforms: All
* Due to a race condition, simultaneous DBOPEN and DBCLOSE operations
could cause a server panic in rare situations.
Assertion failed: prev_link != NULL
server panic: Aborting on internal failure, file vroot.c, line 207
Patch PE62-9905110
------------------
Platforms: All
* A zero record number in the free record list causes a panic in
Node_RemoveFirstItem() during DBPUT. This patch adds a workaround
to handle this particular case more gracefully and ignore the
offending list entry.
Assertion failed: item_ptr->id
server panic: Aborting on internal failure, file nodeilist.c, line 658
Patch PE62-9904120
------------------
Platforms: All
* Transaction isolation in the fixrec subsystem did not work correctly.
This could cause a server panic if a commit operation was executed
concurrently to a read operation.
Assertion failed: f_bhp->id.node_id == node_id
server panic: Aborting on internal failure, file mpool.c, line 391
Assertion failed: Pool_TestFlag(Pool_BLOCKUSED, &header)
server panic: Aborting on internal failure, file volpool.c, line 2372
Patch PE62-9904090
------------------
Platforms: All
* dbctl dbstore could cause a PIN leak when running out of disk space.
This will lead to a subsequent server panic.
* dbctl dbrestore may cause a server panic when using dbutil
subsequently.
Assertion failed: f_bhp->id.node_id == node_id
server panic: Aborting on internal failure, file mpool.c, line 391
Assertion failed: header.size >= addr->size
server panic: Aborting on internal failure, file volpool.c, line 3456
Patch PE62-9904080
------------------
Platforms: All
* dbctl backup stop could cause a eloqdb6 panic.
Assertion failed: hash_table[ndx] != NULL
server panic: Aborting on internal failure, file volredir.c, line 207
* A eloqdb6 crash during on-line backup could cause a subsequent
failure to open the volume files.
Unable to open data base volumes.
Vol_Open() failed with VOLE018
Patch PE62-9904060
------------------
Platforms: All
* Crash recovery could fail with an internal problem.
server panic: Fatal problem detected in Node_RecoverItemPage
Assertion failed: rec->prev_page_timestamp == prev_ilist->timestamp + 1
server panic: Aborting on internal failure, file nodeilist.c, line 1314
Patch PE62-9903311
------------------
Platforms: All
* Crash recovery could fail with internal error.
Assertion failed: iter->anch->last_block.offset == iter->addr.offset
server panic: Aborting on internal failure, file volpool.c, line 136
* A corner case with disabling on-line backup mode could cause
data corruption if a checkpoint operation was executed concurrently.
* Disabling on-line backup mode could cause a server hang.
* A server crash while in backup on-line mode could cause an internal
failure the next time on-line backup mode was enabled.
Assertion failed: !Vol_TestFlag(Vol_IS_REDIRECTED, &root_vol[idx].header))
server panic: Aborting on internal failure, file volredir.c, line 568
Due to a related reason, dbfsck or dbvolextend could refuse to
modify a volume, complaining that the volume is still in on-line
backup mode.
* dblogreset shares the same recovery routines as the eloqdb6 server.
So a new version is included in this patch.
Patch PE62-9903290
------------------
Platforms: All
* eloqdb6 could abort with an internal failure.
Assertion failed: header.size >= addr->size
server panic: Aborting on internal failure, file volpool.c, line 1985
Assertion failed: Pool_TestFlag(Pool_BLOCKUSED,&header)
server panic: Aborting on internal failure, file volpool.c, line 2132
* When a client was disconnected (killed) eloqdb6 could cause a high
load when the associated internal thread was blocked.
For example, when eloqcore is blocking on a DBLOCK and is killed
the eloqdb6 process could busy waiting until the lock becomes
available, consuming almost all CPU resources.
Patch PE62-9903080
------------------
Platforms: All
* Crash recovery could cause fixrec meta data corruption.
This could either cause image status errors status 17 or -96 or lead
to a eloqdb6 server panic.
Assertion failed: FixRec_FinalCommitDelete(): record counter inconsistency
server panic: Aborting on internal failure, file volfrec.c, line 3089
The dbfsck utlity can be used to verify or correct fixrec meta information.
* Crash recovery could leave unassigned index and system catalog data
pages. In rare situations, this could lead to data corruption.
* dbctl dbrestore could cause a deadlock.
When a database is restored, user/group memberships are deleted.
This could cause a deadlock.
Patch PE62-9902222
------------------
Platforms: All
* DBUPDATE mode 1 on a standalone detail set returned status 41
Patch PE62-9902221
------------------
Platforms: All
* DBFIND/DBGET on index item or QFIND on index item could fail.
Patch PE62-9902170
------------------
Platforms: All
* A race condition could cause a eloqdb6 panic.
Assertion failed: bhp->id.page_id == ++page_id
server panic: Aborting on internal failure, file mpool.c, line 415
This was triggered by a low buffer space condition where a buffer
page was re-used unexpectedly by the same thread.
* A race condition in Node_Open() could cause a eloqdb6 panic.
Assertion failed: meta
server panic: Aborting on internal failure, file volfrec.c, line 2274
This was triggered by a condition where multiple threads were
opening a node and the first one was blocked to read the node
meta data.
* On the HP-UX and Linux platform a server shutdown could cause
errorneous messages.
Patch PE62-9902110
------------------
Platforms: All
* dbvolcreate utility could output errorneous warnings about
a possible PIN LEAK.
* The eloqdb6 server process could output errorneous warnings about
a possible PIN LEAK.
* The dbstore operation failed to release a node lock which could cause
a subsequent eloqdb6 server panic.
* After opening more than 32767 databases in succession in a single
session eloqdb6 could provide a possibly wrong or duplicate dbid.
Installation:
-------------
UNIX:
In order to install this patch, you need to unpack it with gzip.
Gzip is included with HP-UX 10.x and Linux.
Installation requires root privileges.
cd /opt/eloquence6
gzip -dc /path/to/PE62-0009080-hpux.tar.gz | tar xf -
Files:
bin/eloqdb6
bin/dbvolcreate
bin/dblogreset
share/doc/PE62-0009080-README
Windows NT:
This patch should *only* be installed if you previously installed the
HP Eloquence server components on your system.
Download the PE62-0009080-win32.zip file and unpack with WINZIP or PKZIP.
Installation requires administrative capabilities.
PLEASE MAKE SURE THE EloqDB6 SERVICE has been STOPPED previously
(in the Service Control Manager). Please copy the eloqdb6.exe file
into the WINDOWS SYSTEM DIRECTORY (for example C:/WINNT/SYSTEM32)
and the dbvolcreate.exe and dblogreset.exe files to the bin subdirectory
of your HP Eloquence installation directory (for example
C:/Programs/Hewlett-Packard/HP Eloquence/bin).
Files:
eloqdb6.exe
dbvolcreate.exe
dblogreset.exe
PE62-0009080-README.txt