From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 25 Oct 2018 11:31:57 +0300 From: Vladimir Davydov Subject: Re: [PATCH v2 4/4] wal: delete old wal files when running out of disk space Message-ID: <20181025083157.rgc5vtt5d7ghgaqj@esperanza> References: <20181023184645.GC29694@chai> <20181024095116.ldsc3j2dn4kmzsjy@esperanza> <20181024165334.GC12973@chai> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181024165334.GC12973@chai> To: Konstantin Osipov Cc: tarantool-patches@freelists.org List-ID: On Wed, Oct 24, 2018 at 07:53:34PM +0300, Konstantin Osipov wrote: > * Vladimir Davydov [18/10/24 12:55]: > > No, this isn't true. WAL watcher was introduced as a generic > > notification channel built over cbus in the first place. Before > > it was made available, we used inotify to track WAL directory > > changes in relays. > > > > > Now you can send a direct message to gc. Why use wal watcher api at > > > all? > > > > Because we already have a generic abstraction, and I think we'd better > > use it instead of adding another wal-tx pipe to the wal_thread and > > implementing home-brewed notifications on top of it. > > Well, the pipe costs nearly nothing at runtime. It is point to > point delivery. The watcher api is broadcast by nature. Can't we use > the existing pipe? We no longer delete any files on the receiving > side. We still need to invoke gc_run() upon receiving a message, because the WAL thread deletes WAL files only until it can proceed while there may be more to delete after a replica is discarded. Besides, when we finally implement persistent garbage collector we'll have to unregister stale replicas in the message handler, which implies yielding. If we decided to use the existing WAL -> TX pipe, we'd have to do the same work the watcher implementation already does so why not reuse it if we already have it?