From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sun, 9 Dec 2018 00:41:38 +0300 From: Konstantin Osipov Subject: Re: [PATCH v2 01/10] gc: do not use WAL watcher API for deactivating stale consumers Message-ID: <20181208214138.GC2217@chai> References: <4bf53c681235b88572831006587fe40dd4881e76.1544282224.git.vdavydov.dev@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4bf53c681235b88572831006587fe40dd4881e76.1544282224.git.vdavydov.dev@gmail.com> To: Vladimir Davydov Cc: tarantool-patches@freelists.org List-ID: * Vladimir Davydov [18/12/09 00:15]: > 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. OK to push. -- Konstantin Osipov, Moscow, Russia, +7 903 626 22 32 http://tarantool.io - www.twitter.com/kostja_osipov