From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <korablev@tarantool.org>
Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149])
 (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 106D546970E
 for <tarantool-patches@dev.tarantool.org>;
 Wed, 15 Jan 2020 19:36:34 +0300 (MSK)
Received: by smtpng3.m.smailru.net with esmtpa (envelope-from
 <korablev@tarantool.org>) id 1irlek-0005In-He
 for tarantool-patches@dev.tarantool.org; Wed, 15 Jan 2020 19:36:34 +0300
Date: Wed, 15 Jan 2020 19:36:34 +0300
From: Nikita Pettik <korablev@tarantool.org>
Message-ID: <20200115163634.GA82780@tarantool.org>
References: <0a9dc9f36c43ab8c9f8e16660a8c9e33074d3ae4.1578904897.git.korablev@tarantool.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <0a9dc9f36c43ab8c9f8e16660a8c9e33074d3ae4.1578904897.git.korablev@tarantool.org>
Subject: Re: [Tarantool-patches] [PATCH] sql: account prepared stmt cache
 size right after entry removal
List-Id: Tarantool development patches <tarantool-patches.dev.tarantool.org>
List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=unsubscribe>
List-Archive: <https://lists.tarantool.org/pipermail/tarantool-patches/>
List-Post: <mailto:tarantool-patches@dev.tarantool.org>
List-Help: <mailto:tarantool-patches-request@dev.tarantool.org?subject=help>
List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=subscribe>
To: tarantool-patches@dev.tarantool.org

On 13 Jan 12:50, Nikita Pettik wrote:
> SQL prepared statement cache is implemented as two data structures: hash
> table <stmt_id : pointer-to-metadata> and GC queue. The latter is
> required to avoid workload spikes on session's disconnect: instead of
> cleaning up memory for all session-local prepared statements, prepared
> statements to be deleted are moved to GC queue. When memory limit for PS
> is reached, all elements from queue are removed at once. If statement
> traps to the GC queue it is assumed to be already dead. Accidentally,
> change of occupied by PS cache takes place only after GC queue clean-up,
> so correct size of PS cache is displayed only after GC cycles. Let's fix
> this and account PS cache size change right after entry removal (i.e. at
> the moment PS gets into GC queue).
> ---
> Branch: https://github.com/tarantool/tarantool/tree/np/fix-prepared-stmt-cache-size-calc
> 
>  src/box/sql_stmt_cache.c   | 2 +-
>  test/sql/prepared.result   | 9 +++++++++
>  test/sql/prepared.test.lua | 3 +++
>  3 files changed, 13 insertions(+), 1 deletion(-)

Pushed to master and 2.3 as obvious. Also it resolves accidental test
failure (sql/prepared.test.lua) on Travis/GitLab.