Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1is5UH-0000CC-SO for pgsql-hackers@arkaria.postgresql.org; Thu, 16 Jan 2020 13:47:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1is5UG-0003x5-K2 for pgsql-hackers@arkaria.postgresql.org; Thu, 16 Jan 2020 13:47:04 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1is5UG-0003wx-3X for pgsql-hackers@lists.postgresql.org; Thu, 16 Jan 2020 13:47:04 +0000 Received: from mail-wm1-x343.google.com ([2a00:1450:4864:20::343]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1is5U9-0000BA-41 for pgsql-hackers@postgresql.org; Thu, 16 Jan 2020 13:47:02 +0000 Received: by mail-wm1-x343.google.com with SMTP id d139so7222748wmd.0 for ; Thu, 16 Jan 2020 05:46:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Gszz8TOuU546jjZAQtkvuskZpG6+xkzrthYM9+T9TjQ=; b=q3fZAfdB2wJQIFIc9Gh8ZwVYU9yPj1jl9okcx+FNt6WqKcUTNdNfbItoTiVobhu+A8 XtdvKxU+UqhXwGYy6SX8L0qELVcF8QRZZQK1mj7p0LIVKnTlgtAOFqFheMSnVvSeVvm3 uBHUWoMfPu8H9gV4yHC4ZAG+y6PghmechmRG+GhMXVhEWjSpbUw9nNnHsmZ+k4wEOKRl 5nOIbqjT+GTcmYGmj0WQ4tVNy1Lg/swI6988CwJofpavhJxI7MvVzMG7AWz0NgiVbC1u Q9bYDrmfWYcjvZSHGPpF3VgBka0hs5oihCTr8imvK+1t01hwFI++SlUuD6MaziLgdr03 IgOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Gszz8TOuU546jjZAQtkvuskZpG6+xkzrthYM9+T9TjQ=; b=WOPeCI84Q/BOAaEw6WPdVsX50sqWtr8+a7TmWiMbIa7X2cCxZNlypdgG/uchT6vEGu oNtgAPdFozrLOqxcuqKIlQT6hE/16iWuawqy+VtoN7JNxyfIsTTAxKjXU5QYPBkXHdFr aYgc80DQFdOfa2OoxXDTlH7dxEn5cqcsai+Jr0FhGpNbpByrbwmGnPzyrEqBrpkDIUU2 TI7ojoqOYFY6iAmmNkVew0pu6nT9VadASxTZbQEsp3UUMrFLD7kTtEVtjFBOyDd+KLDL 7HLg6SM8OtNdeMaEDiY++1OLdsTYeZJHirMecb6kaf2txp3Jj410NbRtGV7siI3qspjN B0eA== X-Gm-Message-State: APjAAAUzp8hDevyRBxJsLQhNdNDfwQiuQ3JUrtjag28cOgsg9Xl9esQ4 p06Z1Uk4KDackKy70YK5mx4ikpukJAc= X-Google-Smtp-Source: APXvYqxWhPDKkmpAtQuM1ZWF4ZwfbYtmQc+Gz8ht+NqwToYHN8+P/tz+kR/Hr202P6KbWyBIrzTYjw== X-Received: by 2002:a1c:730b:: with SMTP id d11mr6639607wmb.30.1579182415465; Thu, 16 Jan 2020 05:46:55 -0800 (PST) Received: from localhost (static-84-42-175-93.net.upcbroadband.cz. [84.42.175.93]) by smtp.gmail.com with ESMTPSA id g9sm29539816wro.67.2020.01.16.05.46.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Jan 2020 05:46:54 -0800 (PST) Date: Thu, 16 Jan 2020 14:46:52 +0100 From: Tomas Vondra To: Andres Freund Cc: Tom Lane , Tomas Vondra , pgsql-hackers@postgresql.org Subject: Re: SlabCheck leaks memory into TopMemoryContext Message-ID: <20200116134652.3myxa6rgo652oovk@development> References: <20200116044119.g45f7pmgz4jmodxj@alap3.anarazel.de> <23952.1579151393@sss.pgh.pa.us> <20200116061732.vvpyexenaortpu5y@alap3.anarazel.de> <27213.1579155900@sss.pgh.pa.us> <20200116064143.opcu2vhcktddpzbh@alap3.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20200116064143.opcu2vhcktddpzbh@alap3.anarazel.de> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Wed, Jan 15, 2020 at 10:41:43PM -0800, Andres Freund wrote: >Hi, > >On 2020-01-16 01:25:00 -0500, Tom Lane wrote: >> Andres Freund writes: >> > On 2020-01-16 00:09:53 -0500, Tom Lane wrote: >> >> It's basically assuming that the memory management mechanism is sane, >> >> which makes the whole thing fundamentally circular, even if it's >> >> relying on some other context to be sane. Is there a way to do the >> >> checking without extra allocations? >> >> > Probably not easily. >> >> In the AllocSet code, we don't hesitate to expend extra space per-chunk >> for debug support: >> >> typedef struct AllocChunkData >> { >> ... >> #ifdef MEMORY_CONTEXT_CHECKING >> Size requested_size; >> #endif >> ... >> >> I don't see a pressing reason why SlabContext couldn't do something >> similar, either per-chunk or per-context, whatever makes sense. > >Well, what I suggested upthread, was to just have two globals like > >int slabcheck_freechunks_size; >bool *slabcheck_freechunks; > >and realloc that to the larger size in SlabContextCreate() if necessary, >based on the computed chunksPerBlock? I thought you were asking whether >any additional memory could just be avoided... > I don't see why not to just do what Tom proposed, i.e. allocate this as part of the memory context in SlabContextCreate(), when memory context checking is enabled. It seems much more convenient / simpler than the globals (no repalloc, ...). regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services