From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 3238130174 for ; Thu, 29 Nov 2018 12:02:47 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrLJVTB8-SAK for ; Thu, 29 Nov 2018 12:02:47 -0500 (EST) Received: from smtp57.i.mail.ru (smtp57.i.mail.ru [217.69.128.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 91AFE30155 for ; Thu, 29 Nov 2018 12:02:46 -0500 (EST) Received: by smtp57.i.mail.ru with esmtpa (envelope-from ) id 1gSPi8-0003WG-62 for tarantool-patches@freelists.org; Thu, 29 Nov 2018 20:02:44 +0300 Date: Thu, 29 Nov 2018 20:02:42 +0300 From: Konstantin Osipov Subject: [tarantool-patches] Re: [PATCH 5/9] gc: do not use WAL watcher API for deactivating stale consumers Message-ID: <20181129170242.GE5760@chai> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-subscribe: List-owner: List-post: List-archive: To: tarantool-patches@freelists.org * Vladimir Davydov [18/11/28 19:16]: > The WAL thread may delete old WAL files if it gets ENOSPC error. > Currently, we use WAL watcher API to notify the TX thread about it so > that it can shoot off stale replicas. This looks ugly, because WAL > watcher API was initially designed to propagate WAL changes to relay > threads and the new event WAL_EVENT_GC, which was introduced for > notifying about ENOSPC-driven garbage collection, isn't used anywhere > else. Besides, there's already a pipe from WAL to TX - we could reuse it > instead of opening another one. > > If we followed down that path, then in order to trigger a checkpoint > from the WAL thread (see #1082), we would have to introduce yet another > esoteric WAL watcher event, making the whole design look even uglier. > That said, let's rewrite the garbage collection notification procedure > using a plane callback instead of abusing WAL watcher API. Thank you for the patch. As discussed, let's avoid invoking garbage collection from txn.cc, WAL can alert tx explicitly whenever an exceptional situation such as ENOSPC happens. > + /** > + * Set if the WAL thread ran out of disk space while > + * processing this request and had to delete some old > + * WAL files. > + */ > + bool gc_executed; This will be unnecessary if we send a special message. If you are worried about OOM when creating such a message, you could a) ignore the message b) use a preallocated one, stored in struct wal. -- Konstantin Osipov, Moscow, Russia, +7 903 626 22 32 http://tarantool.io - www.twitter.com/kostja_osipov