From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/85859 Path: news.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.gnus.general Subject: Re: Trying to prune the registry because it's full; apply: registry max-size limit reached Date: Mon, 30 Mar 2015 15:15:11 +0800 Message-ID: <87ego7ot1c.fsf@ericabrahamsen.net> References: <87twx3ypx7.fsf@gnu.org> <87iodjotuo.fsf@ericabrahamsen.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: ger.gmane.org 1427699792 26526 80.91.229.3 (30 Mar 2015 07:16:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 30 Mar 2015 07:16:32 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M34094@lists.math.uh.edu Mon Mar 30 09:16:20 2015 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from lists1.math.uh.edu ([129.7.128.208]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YcTvm-0006Z4-GK for ding-account@gmane.org; Mon, 30 Mar 2015 09:16:18 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.84) (envelope-from ) id 1YcTvF-0008Sm-IB; Mon, 30 Mar 2015 02:15:45 -0500 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by lists1.math.uh.edu with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.84) (envelope-from ) id 1YcTvD-0008SN-Ev for ding@lists.math.uh.edu; Mon, 30 Mar 2015 02:15:43 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtps (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1YcTvC-0007ZU-MO for ding@lists.math.uh.edu; Mon, 30 Mar 2015 02:15:43 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]) by quimby.gnus.org with esmtp (Exim 4.80) (envelope-from ) id 1YcTv8-0003r0-7K for ding@gnus.org; Mon, 30 Mar 2015 09:15:38 +0200 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YcTus-000618-SI for ding@gnus.org; Mon, 30 Mar 2015 09:15:25 +0200 Original-Received: from 114.248.25.174 ([114.248.25.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 30 Mar 2015 09:15:22 +0200 Original-Received: from eric by 114.248.25.174 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 30 Mar 2015 09:15:22 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 116 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 114.248.25.174 User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:ZfQdC6Iv+sFalLVSrDJ9Dvdlv7A= X-Spam-Score: 0.3 (/) X-Spam-Report: SpamAssassin (3.4.0 2014-02-07) analysis follows Bayesian score: 0.0000 Ham tokens: 0.000-240--16412h-0s--0d--git, 0.000-226--15483h-0s--0d--diff, 0.000-223--15233h-0s--0d--100644, 0.000-203--13859h-0s--0d--insertions, 0.000-171--11672h-0s--0d--deletions Spam tokens: 0.994-5554--198h-2533s--0d--HTo:D*gnus.org, 0.994-5873--211h-2679s--0d--Hx-spam-relays-external:quimby.gnus.org, 0.994-5873--211h-2679s--0d--H*RU:quimby.gnus.org, 0.993-5834--250h-2679s--0d--Hx-spam-relays-internal:80.91.231.51, 0.993-5834--250h-2679s--0d--H*RT:quimby.gnus.org Autolearn status: no autolearn_force=no -1.0 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [80.91.229.3 listed in list.dnswl.org] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 1.2 RCVD_NUMERIC_HELO Received: contains an IP address used for HELO -0.0 SPF_PASS SPF: sender matches SPF record -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 2.0 FSL_HELO_BARE_IP_2 No description available. List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:85859 Archived-At: --=-=-= Content-Type: text/plain Eric Abrahamsen writes: > Tassilo Horn writes: > >> Hi all, >> >> just now when I wanted to enter this group, I got the error message >> >> Trying to prune the registry because it's full >> apply: registry max-size limit reached >> >> with this backtrace: >> >> Debugger entered: ((cl-assertion-failed (not (registry-full db)) "registry max-size limit reached")) >> cl--assertion-failed((not (registry-full db)) "registry max-size limit reached" nil nil) >> registry-insert([eieio-class-tag--registry-db "~/.gnus.d/.gnus.registry.eieio" 0.2 10000 0.1...]) >> gnus-registry-insert( "<59afc63a-24c7-4b7b-89d8-4b99ba1f3b5b@googlegroups.com>" ((creation-time (21784 58735 12080 293000)) (group) (sender) (subject))) >> gnus-registry-get-or-make-entry("<59afc63a-24c7-4b7b-89d8-4b99ba1f3b5b@googlegroups.com>") >> gnus-registry-get-id-key("<59afc63a-24c7-4b7b-89d8-4b99ba1f3b5b@googlegroups.com>" group) >> gnus-registry-register-message-ids() >> run-hooks(gnus-summary-prepare-hook) >> apply(run-hooks gnus-summary-prepare-hook) >> gnus-run-hooks(gnus-summary-prepare-hook) >> gnus-summary-prepare() >> gnus-summary-read-group-1("nnimap+Fastmail:INBOX.mailinglists.clojure" nil t nil nil nil) >> gnus-summary-read-group("nnimap+Fastmail:INBOX.mailinglists.clojure" nil t nil nil nil nil) >> gnus-group-read-group(nil t) >> gnus-group-select-group(nil) >> gnus-topic-select-group(nil) >> funcall-interactively(gnus-topic-select-group nil) >> call-interactively(gnus-topic-select-group nil nil) >> command-execute(gnus-topic-select-group) >> >> >> My registry-related settings are just >> >> (setq gnus-registry-ignored-groups '(("^nntp" t) ("^nndraft" t) >> ("^nnir" t) >> ("training" t) ("Junk" t) >> ("Trash" t) ("Spam" t)) >> ;; Don't track anything except for the message ids. >> gnus-registry-track-extra nil >> gnus-registry-max-entries 10000) >> >> (gnus-registry-initialize) >> >> I had thought that with a maximum number of entries, as soon as I hit >> it, the registry would prune the oldest entries to regain some space. >> But according to the messages, it seems that pruning didn't succeed. > > This is related to a change I made recently. What used to happen was -- > assuming max entries of 10000 and a prune factor of 0.1 -- every time > the registry exceeded 9000 (not 10000), it would prune. That wasn't what > was supposed to happen: it was supposed to hit 10000 and then prune back > to 9000. > > A few days ago I changed it so that it really did reach its max size > before pruning. Obviously something isn't quite aligned right. I'm > assuming some sort of off-by-one error: we're using #'< where we should > be using #'<=, or something like that. Embarrassingly, that is indeed what was happening. Would you mind giving this patch a whirl? If it works correctly, I'll push it (plus a ChangeLog notice). Sorry about that, Eric --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=0001-Fix-registry-pruning-routine.patch >From 5e9f920ec706393fd9b3a0d260abd13259b26a0d Mon Sep 17 00:00:00 2001 From: Eric Abrahamsen Date: Mon, 30 Mar 2015 15:12:40 +0800 Subject: [PATCH] Fix registry pruning routine * lisp/registry.el (registry-prune): Re-use `registry-full' in `registry-prune'. It's a bit of redundant work, but safer. Also ensure that target-size is an integer. --- lisp/registry.el | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/lisp/registry.el b/lisp/registry.el index c8d7d85..551cee8 100644 --- a/lisp/registry.el +++ b/lisp/registry.el @@ -361,11 +361,12 @@ from the front of the list are deleted first. Returns the number of deleted entries." (let ((size (registry-size db)) - (target-size (- (oref db max-size) - (* (oref db max-size) - (oref db prune-factor)))) + (target-size + (round (- (oref db max-size) + (* (oref db max-size) + (oref db prune-factor))))) candidates) - (if (> size (oref db max-size)) + (if (registry-full db) (progn (setq candidates (registry-collect-prune-candidates -- 2.3.4 --=-=-=--