From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Re: sqlite3 usage for multisession variable storage Date: Wed, 15 Dec 2021 02:34:11 +0100 Message-ID: <875yrqodm4.fsf@gnus.org> References: <87tufmjyai.fsf@gnus.org> <87lf0nr2b4.fsf@gnus.org> <87ee6f5wmy.fsf@telefonica.net> <87czlzqy3a.fsf@gnus.org> <874k7bqptr.fsf@gnus.org> <922b09b2-24b1-6f3f-ce5b-7b07675d3637@dasyatidae.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10871"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Robin Tarsiger Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Dec 15 02:36:38 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mxJDh-0002ec-DX for ged-emacs-devel@m.gmane-mx.org; Wed, 15 Dec 2021 02:36:37 +0100 Original-Received: from localhost ([::1]:60978 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mxJDg-0002CJ-3c for ged-emacs-devel@m.gmane-mx.org; Tue, 14 Dec 2021 20:36:36 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:39290) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mxJBa-0000Yv-Fb for emacs-devel@gnu.org; Tue, 14 Dec 2021 20:34:26 -0500 Original-Received: from [2a01:4f9:2b:f0f::2] (port=36696 helo=quimby.gnus.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mxJBY-0000AY-Cz for emacs-devel@gnu.org; Tue, 14 Dec 2021 20:34:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=dBis6idh8g4UnFq2M1d4I8dBs1SIzjwYmaiNmTENmBk=; b=vBJE/LYPYPReDONLgGRtAfS67C erP7LXQg5CCKiP7HBazbvbVgJQTtC7TrdWpF2Qbe4wVrf458/JsEhVWlsca5XEh65fTxfIV5bGvVT ypx4DMyKCiYsgPAXMoXip8rXDKhfgD0ByBcsFFnae0egqp9IyG8eMeGOttnn92l2/nPI=; Original-Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mxJBQ-00013a-Pa; Wed, 15 Dec 2021 02:34:19 +0100 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAElBMVEXq7e6npqGIgXNf VkkYFBH///+w5t/OAAAAAWJLR0QF+G/pxwAAAAd0SU1FB+UMDwEbNnCA6fIAAAGgSURBVDjLdZTt gcMgCIYx7QBqOkDVDtCoA1wD+890gB9Nrzn+pPIIvKAW4GDG+VS6wYc553P0W4yxDEf7WuOCXwJz ARdEIrKaij25pJgklakkhrYBTuMiE4AHNUMF7EpZIxYatimYqq4T0P0DvP307IDwD3gJqKqlDrA5 Xu8muNQ3NSBSb/x1YfgbED+sAlwdAEF1Sv/8I3s6Agw6WVndTgDceGJjCplrVE1lAK7bLEDbA6Xz YH0GWO5vsF94cpVy8OXOh9IB8s6FAYe8Fh26AkSUcFSdL9D6DXBbKayone0qa22CEoKza0uFCrrW rdrbZvYOjD2AJ6/2Nr072J5q53mxQoht38+swfIU+HYe2VkwrXiA+uLw1ADKVBrYoaeawLXi6BK8 gV6dfvFiCh/A+T6q54NLLANgDOu4XfEICEcAZTnpywRU5qFKiRKPF27eYQb5BCC/orWcAIk5BdLt 5QzoseX/wLcqrKLKMOiNzf7SaBD7xjEbHyTgKxVG/jMw/HQ1VT0EFX3MAvBdtm3QR3sASBWp1IID DD2IBcXZwS99p9AznJ08HgAAACV0RVh0ZGF0ZTpjcmVhdGUAMjAyMS0xMi0xNVQwMToyNzo1NCsw MDowMCwReJoAAAAldEVYdGRhdGU6bW9kaWZ5ADIwMjEtMTItMTVUMDE6Mjc6NTQrMDA6MDBdTMAm AAAAAElFTkSuQmCC X-Now-Playing: Tears For Fears's _Songs From The Big Chair_: "The Big Chair" In-Reply-To: <922b09b2-24b1-6f3f-ce5b-7b07675d3637@dasyatidae.com> (Robin Tarsiger's message of "Tue, 14 Dec 2021 17:41:12 -0600") X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a01:4f9:2b:f0f::2 (failed) Received-SPF: pass client-ip=2a01:4f9:2b:f0f::2; envelope-from=larsi@gnus.org; helo=quimby.gnus.org X-Spam_score_int: -35 X-Spam_score: -3.6 X-Spam_bar: --- X-Spam_report: (-3.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:281960 Archived-At: Robin Tarsiger writes: > The difference is in crash recovery; if one instance crashes hard in the > middle of a transaction, it's "restore the file from backup" time. > Whether that's okay depends on your surrounding strategy, but it feels > similar to a subset of the lockfile strategies Emacs already considers > okay. It's the "restore from backup" thing that's not acceptable, which makes MEMORY unworkable here, I think. > Hmm. What pattern/frequency/relative-frequency of reads/writes is expected > to be common for these variables? And in particular, what about read- > modify-write operations? Will applications tend to expect these to be > atomic (deliberately or otherwise)? I expect the writes to typically not happen very often. But it's nice that they're fast if somebody has a use case for updating a lot. > If you want periodic maintenance of the DB file, there may also be > application-level maintenance that would be useful, as I extrapolate it? > Depending on what's stored in these variables, clearing out stale entries > and the like may want to be done at an elisp level. Leaving cleanup+VACUUM > to be done explicitly on timer or user request and then having a hook for > the non-DB-format-related cleanup might be workable? Not sure. There's really no way of knowing whether a value is "stale" -- there's no central list of which keys are in use. > It cheaply removes a little chunk of potentially surprising behaviors. But > you may be right in a sense---it depends on whether elisp assumes it can > trust values read from the store. If so, then the entire DB is just in the > same "may do anything" trusted zone as the rest of .emacs.d, I suppose? Yes, it doesn't seem to be a significant attack vector in this context. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no