From: Adolf Belka <adolf.belka@ipfire.org>
To: development@lists.ipfire.org
Subject: [PATCH] gdbm: Update to version 1.23
Date: Tue, 15 Feb 2022 10:36:18 +0100 [thread overview]
Message-ID: <20220215093618.188149-1-adolf.belka@ipfire.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 4626 bytes --]
- Update from 1.20 to 1.23
- Update of rootfile not required
- Changelog
Version 1.23, 2022-02-04
* Bucket cache switched from balanced tree to hash table
Change suggested by Terence Kelly.
* Speed up flushing the changed buckets on disk
* New option codes for gdbm_setopt
** GDBM_GETDBFORMAT
Return the database format.
** GDBM_GETDIRDEPTH
Return the directory depth, i.e. the number of initial (most significant)
bits in hash value that are interpreted as index to the directory.
** GDBM_GETBUCKETSIZE
Return maximum number of keys per bucket.
** GDBM_GETCACHEAUTO
Return the status of the automatic cache adjustment.
** GDBM_SETCACHEAUTO
Enable or disable automatic cache adjustment.
Version 1.22, 2021-10-19
* Fix file header validation
* Fix key verification in sequential access
* Fix testing with DejaGNU 1.6.3
* Fix stack overflow in print_usage
* Fix a leak of avail entry on pushing a new avail block
The leak would occur if the original avail table had odd number of entries.
* New gdbmtool variables: errorexit, errormask, trace, timing
"Errorexit" and "errormask" control which GDBM errors would cause the
program termination and emitting a diagnostic message,
correspondingly. Both variables are comma-delimited lists of error
codes.
The "trace" variable enables tracing of the gdbmtool commands.
The "timing" variable, when set, instructs gdbmtool to print time
spent in each command it runs.
* New gdbmtool options: -t (--trace), and -T (--timing)
Version 1.21, 2021-09-02
* Crash tolerance
By default it is possible for an abrupt crash (e.g., power failure,
OS kernel panic, or application process crash) to corrupt the gdbm
database file. A new Linux-only mechanism enables applications to
recover the database state corresponding to the most recent
successful gdbm_sync() call before the crash. See the chapter 17
"Crash Tolerance" in the GDBM manual.
* New database file format: numsync
The new "numsync" database format is designed to better support
crash tolerance. To create a database in numsync format, the gdbm_open
(or gdbm_fd_open) function must be given the GDBM_NEWDB|GDBM_NUMSYNC
flags. The GDBM_NUMSYNC flag also takes effect when used together
with GDBM_WRCREAT, provided that the new file is created.
New function gdbm_convert() is provided for converting the databases
from standard GDBM format to numsync and vice versa.
The gdbmtool tool can also be used for converting databases between
these two formats.
* Changes in gdbmtool
** Fix string output in non-ASCII encodings
Printable multi-byte sequences are correctly represented on output.
This also fixes octal representation of unprintable characters.
** The filename variable
This variable supplies the name of database file for use in "open"
command, if the latter is called without arguments. If "open" is
called with the file name argument, the "filename" variable is
initialized to this value.
** The fd variable
If set, its value must be an open file descriptor referring to a
GDBM database file. The "open" command will use gdbm_fd_open
function to use this file. Upon closing the database, this
descriptor will be closed and the variable will be unset.
The file descriptor to use can also be supplied using the
-d (--db-descriptor) command line option.
** The format variable
Defines the format in which new databases will be created. Allowed
values are: "standard" (default) and "numsync".
** New commands: upgrade and downgrade
The "upgrade" command converts current database to the numsync
(extended) format. The "downgrade" command converts current database
to the standard format.
** New command: snapshot
The "snapshot" command is part of the new crash tolerance support.
Given the names of two snapshot files, it analyzes them and selects
the one to be used for database recovery. See the GDBM manual,
section 17.5 "Manual crash recovery" for a detailed discussion of its
use.
Signed-off-by: Adolf Belka <adolf.belka(a)ipfire.org>
---
lfs/gdbm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lfs/gdbm b/lfs/gdbm
index 6f96d2f3c..fa1b2d860 100644
--- a/lfs/gdbm
+++ b/lfs/gdbm
@@ -24,7 +24,7 @@
include Config
-VER = 1.20
+VER = 1.23
THISAPP = gdbm-$(VER)
DL_FILE = $(THISAPP).tar.gz
@@ -40,7 +40,7 @@ objects = $(DL_FILE)
$(DL_FILE) = $(DL_FROM)/$(DL_FILE)
-$(DL_FILE)_MD5 = 006c19b8b60828fd6916a16f3496bd3c
+$(DL_FILE)_MD5 = 8551961e36bf8c70b7500d255d3658ec
install : $(TARGET)
--
2.35.1
next reply other threads:[~2022-02-15 9:36 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-15 9:36 Adolf Belka [this message]
2022-02-15 17:04 ` Peter Müller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220215093618.188149-1-adolf.belka@ipfire.org \
--to=adolf.belka@ipfire.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox