Why does gpg -k write to tofu.db?

[Brian Minton]

I have a lot of public keys in my keybox (it's about 45 MB or so).  I
was trying to figure out why seemingly innocent tasks in gpg take a very
long time.  It seems that gnupg is making a very long running
transaction to the sqlite3 database ~/.gnupg/tofu.db 


laptop:~/.gnupg$ date;ls -last
Tue 11 Aug 2020 03:38:14 PM EDT
total 101184
    4 drwxr-xr-x 109 bminton bminton     4096 Aug 11 15:35 ..
   12 drwx------   5 bminton bminton    12288 Aug 11 15:17 .
  112 -rw-r--r--   1 bminton bminton   111320 Aug 11 15:16 tofu.db-journal
    4 -rw-------   1 bminton bminton      600 Aug 11 15:16 random_seed
 2580 -rw-r--r--   1 bminton bminton  2637824 Aug 11 15:16 tofu.db
    0 -rw-------   1 bminton bminton        0 Aug 11 15:16 tofu.db-want-lock
    4 -rw-r--r--   1 bminton bminton       26 Aug 11 15:05 .#lk0xxxxx...

So, this seems like the transaction has been running for at least 20
minutes.  That's just to run gpg -k

Why does gpg -k need to write to the tofu db?  I should mention that gpg
is running at 100% cpu in the R state.  Before starting the gpg -k
command, I killed all gpg processes with gpgconf --kill all just to make
sure there was no other process trying to talk to gpg.

This seems like it may also be related to https://dev.gnupg.org/T1938 or
https://dev.gnupg.org/T2019 but I'm not sure.

Some version info:
gpg (GnuPG) 2.2.20
libgcrypt 1.8.4
Linux kernel 5.5.0
Debian 10 (buster) + backports
arch: x86_64


hardware:
Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz with 4 cores (note that gpg
only seems to be pegging one core)
16 GB RAM
SATA SSD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20200811/7d83ae40/attachment.sig>