From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp38.i.mail.ru (smtp38.i.mail.ru [94.100.177.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 9926146970E for ; Tue, 21 Jan 2020 15:39:31 +0300 (MSK) Date: Tue, 21 Jan 2020 15:39:30 +0300 From: Kirill Yukhin Message-ID: <20200121123930.5cuaj4j6ypfpsvlo@tarantool.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [Tarantool-patches] [PATCH 1/1] txn: don't trust group id in remote request header List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladislav Shpilevoy Cc: tarantool-patches@dev.tarantool.org Hello, On 15 янв 22:24, Vladislav Shpilevoy wrote: > Transaction adds a redo log for each statement. The log is an xrow > header. Some requests don't have a header (local requests), some > do (from remote client, from replication). > > When a request had a header, it was written as is to WAL. But > requests from remote client have an xrow header, however barely > filled. Most of its fields are default values, usually 0. > Including group id. Indeed, remote clients should not care about > setting such deep system fields. > > That led to a problem when a space had group id local (!= 0), but > it was ignored because in a request header from a remote client > the group id was default (== 0). On the summary, it was possible > to force Tarantool to replicate a replica-local space. > > Now group id setting is server-authoritative. Box always sets it > regardless of what is present in an xrow header received from a > client. > > Thanks Kostja Osipov (@kostja) for the diagnostics and the > solution. > > Closes #4729 I've checked your patch into 2.2, 2.3 and master. -- Regards, Kirill Yukhin