From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 4O7qJxMp2V7wcQAA0tVLHw (envelope-from ) for ; Thu, 04 Jun 2020 17:02:11 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id +LbhIxMp2V6oWgAA1q6Kng (envelope-from ) for ; Thu, 04 Jun 2020 17:02:11 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id E59209407C6 for ; Thu, 4 Jun 2020 17:02:10 +0000 (UTC) Received: from localhost ([::1]:40272 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jgtFo-0003yn-D0 for larch@yhetil.org; Thu, 04 Jun 2020 13:02:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56804) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jgtFi-0003yX-6V for guix-patches@gnu.org; Thu, 04 Jun 2020 13:02:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:35845) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jgtFh-0007An-Sz for guix-patches@gnu.org; Thu, 04 Jun 2020 13:02:01 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jgtFh-0002wY-Pv for guix-patches@gnu.org; Thu, 04 Jun 2020 13:02:01 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#41658] [PATCH] fixes / improvements for (guix store database) Resent-From: Danny Milosavljevic Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 04 Jun 2020 17:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41658 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Ludovic =?UTF-8?Q?Court=C3=A8s?= , Caleb Ristvedt Cc: 41658@debbugs.gnu.org Received: via spool by 41658-submit@debbugs.gnu.org id=B41658.159129006111230 (code B ref 41658); Thu, 04 Jun 2020 17:02:01 +0000 Received: (at 41658) by debbugs.gnu.org; 4 Jun 2020 17:01:01 +0000 Received: from localhost ([127.0.0.1]:47391 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jgtEU-0002uV-Ly for submit@debbugs.gnu.org; Thu, 04 Jun 2020 13:01:01 -0400 Received: from dd26836.kasserver.com ([85.13.145.193]:48230) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jgtES-0002uN-UI for 41658@debbugs.gnu.org; Thu, 04 Jun 2020 13:00:46 -0400 Received: from localhost (80-110-127-207.cgn.dynamic.surfer.at [80.110.127.207]) by dd26836.kasserver.com (Postfix) with ESMTPSA id 1076A3362236; Thu, 4 Jun 2020 19:00:43 +0200 (CEST) Date: Thu, 4 Jun 2020 19:00:40 +0200 From: Danny Milosavljevic Message-ID: <20200604190000.3c454a83@scratchpost.org> In-Reply-To: <87a71i943g.fsf@gnu.org> References: <87ftbernat.fsf@cune.org> <87a71i943g.fsf@gnu.org> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-unknown-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_//Q/Ho3.GHjQ9ZFu5708gxoh"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Spam-Score: -1.0 (-) X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Spam-Score: -1.11 X-TUID: BazhqwDGEA53 --Sig_//Q/Ho3.GHjQ9ZFu5708gxoh Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ludo, Hi Caleb, On Thu, 04 Jun 2020 18:40:35 +0200 Ludovic Court=C3=A8s wrote: > Nice. It would be great if you could report it upstream (Danny and/or > myself can then patch it directly in guile-sqlite3 and push out a > release) and refer to the issue from here. I agree. It's easy to change sqlite-finalize in guile-sqlite3 to call sqlite-reset, basically just adapt (define sqlite-finalize (let ((f (pointer->procedure int (dynamic-func "sqlite3_finalize" libsqlite3) (list '*)))) (lambda (stmt) ;; Note: When STMT is cached, this is a no-op. This ensures caching ;; actually works while still separating concerns: users can turn ;; caching on and off without having to change the rest of their code. (when (and (stmt-live? stmt) (not (stmt-cached? stmt))) (let ((p (stmt-pointer stmt))) (sqlite-remove-statement! (stmt->db stmt) stmt) (set-stmt-live?! stmt #f) (f p)))))) so that it calls sqlite-reset in the "when"'s new "else" branch there. (we could also always call sqlite3_reset on sqlite-finalize anyway, it woul= dn't hurt but it wouldn't help either) I agree that sqlite-finalize should model sqlite's finalization behavior as much as possible. Also, the comment about this being a no-op is not true then anymore. We should definitely also pick up Caleb's comment upstream: + ;; Cached statements aren't reset when sqlite-finalize is invoked on + ;; them. This can cause problems with automatically-started transactions: + ;; + ;; "An implicit transaction (a transaction that is started automatically, + ;; not a transaction started by BEGIN) is committed automatically when t= he + ;; last active statement finishes. A statement finishes when its last cu= rsor + ;; closes, which is guaranteed to happen when the prepared statement is + ;; reset or finalized. Some statements might "finish" for the purpose of + ;; transaction control prior to being reset or finalized, but there is no + ;; guarantee of this." + ;; + ;; Thus, it's possible for an implicitly-started transaction to hang aro= und + ;; until sqlite-reset is called when the cached statement is next + ;; used. Because the transaction is committed automatically only when the + ;; *last active statement* finishes, the implicitly-started transaction = may + ;; later be upgraded to a write transaction (!) and this non-reset state= ment + ;; will still be keeping the transaction from committing until it is next + ;; used or the database connection is closed. This has the potential to = make + ;; (exclusive) write access to the database necessary for much longer th= an + ;; it should be. + ;; + ;; (see https://www.sqlite.org/lang_transaction.html) @Caleb: Could you file an issue at https://notabug.org/guile-sqlite3/guile-sqlite3/= issues and pull request so this is auditable? --Sig_//Q/Ho3.GHjQ9ZFu5708gxoh Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl7ZKLgACgkQ5xo1VCww uqW8HAf+LapIRcQdeHgWmjm9LAW3w8Ww1MFSZhulb/a/GKz4tC5EMCOlnIs7Otaj kdpeQopGmt8lPHNQNYc85jszOZe+ROzDC7+iraeYIXtoVdQGm5uROts8DH25YGDc GiEg+Q77vJtS73u+f2iG/18UCWOsM0Czkgnv1kV7fFb+yedhl+OoPmueyHbZVl/n dHhut5EwuyXRimz0yErqY4atoFrqU9fPWCe7JZHhz+krHhHavE2AUL6TFBroayDf O2m5aWECT7yUNR0wuyUN9NCLQPNuJ9D4WtHn8B+3KYQ6IT9Mj0jtIhwkRk2k/dy4 T0WyJaaKSB5WgM5WYouCeR7OMKfSSg== =hCaa -----END PGP SIGNATURE----- --Sig_//Q/Ho3.GHjQ9ZFu5708gxoh--