From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f193.google.com (mail-lj1-f193.google.com [209.85.208.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 815A14696C3 for ; Thu, 16 Apr 2020 15:38:05 +0300 (MSK) Received: by mail-lj1-f193.google.com with SMTP id v9so7574802ljk.12 for ; Thu, 16 Apr 2020 05:38:05 -0700 (PDT) Date: Thu, 16 Apr 2020 15:38:02 +0300 From: Cyrill Gorcunov Message-ID: <20200416123802.GS3072@uranus> References: <20200416120658.33777-1-sergepetrenko@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200416120658.33777-1-sergepetrenko@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH] relay: move relay_schedule_pending_gc before status update List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Serge Petrenko Cc: tarantool-patches@dev.tarantool.org, v.shpilevoy@tarantool.org On Thu, Apr 16, 2020 at 03:06:58PM +0300, Serge Petrenko wrote: > relay_schedule_pending_gc() is executed after relay status update, > which made perfect sense before we've introduced local spaces rework, making > local space operations use a special instance id: 0. > Relay status update is performed only when the remote instance has > reported a bigger vclock, than its previous one. However, we may have an > entire WAL file filled with local space changes, in which case the > changes won't be transmitted to replica, and it will report the same > vclock as before, postponing the scheduled gc until a non-local row is > created on master. > > Fix this by reordering relay_schedule_pending_gc() and relay status > update. In case nothing new is added to pending_gc queue and replica > clock is not updated, relay_schedule_pending_gc() will exit on the first > loop iteration, so it doesn't add an overhead. > > Also make relay_schedule_pending_gc() use vclock_compare_ignore0() instead > of plain vclock_compare(). > > Follow-up #4114 > --- > This code was present in v5 of the patchset regarding local space replication > rework, but I accidentally threw it away during the review. Sorry. > The letter was "[PATCH v5 2/4] replication: hide 0-th vclock components in > replication responses" > > Branch: https://github.com/tarantool/tarantool/tree/sp/relay-gc-fix Maybe it worth to have two commits? - use vclock_compare_ignore0 in relay_schedule_pending_gc - reorder relay_schedule_pending_gc