Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fnUQg-0008GP-19 for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Aug 2018 19:47:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fnUQc-0006zp-Oj for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Aug 2018 19:47:30 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fnUQc-0006zh-DW for pgsql-hackers@lists.postgresql.org; Wed, 08 Aug 2018 19:47:30 +0000 Received: from mail-wm0-x241.google.com ([2a00:1450:400c:c09::241]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1fnUQU-0000ZA-PH for pgsql-hackers@lists.postgresql.org; Wed, 08 Aug 2018 19:47:29 +0000 Received: by mail-wm0-x241.google.com with SMTP id y9-v6so3963826wma.5 for ; Wed, 08 Aug 2018 12:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=q0FwZ4eFND+hKRKnUaLKzy9C5w1AmjSibN8zulCgT3w=; b=QHcAKWen6PpW/DypUpfYxTQA7W0hBVV9ZFEhhBZUL1Lz9Hq19j9GEOCxTF0x9a4Ooe T96UQ8kc+2euXRzWQqD/z9J75GDptlDGLS+h/2BCsnOJNH/RwOqBLZlKl5AX9LB0XlEH NrfOYNaUbI6t1jC0jWKgrNr/WbTpYNWWEmEDQKEZQiAOCttC/VRixPC8GQWCtS0bZXmF ByMBDfbkKCTyZmZVKwfu65bLVW+p0A51skB6X0LZJwtIZ8B8aMORagUjmw2X6LvyT3S5 7uETAbLELLR7eVwadQCReXSEYi8qG3dOrpH6XYBkua12pVuCnYx1cdBxA/Wo59ShHPkp hpsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=q0FwZ4eFND+hKRKnUaLKzy9C5w1AmjSibN8zulCgT3w=; b=bZ0P7QcTMqI3m18ihnGXbwGH4H1jKlf4/JxxL5dXOT5OAMT2wMauBEqrEpY2ajlwSj N/Cz5bQXYlN41jNtTkxcl7DTzr+6cv9Dycjg9GLnOxPA9n6SFwx8XCoQD0QWNKsD9Fsv UvyRCponNYOkAtV8XB/C9Nu2Sq8uR+rim8VN96swB2Rq/Xsr4X/9WitbhLjVJ2KOX16f HMMi6Fpd+yJFTX5cGuWtM2AAqMZOimzkc8plCpraVR/2lKAfvkSdmmkG4FgnPCboud4N Izv90KnWlu79G+x8sNG1zWa+k3i4H5CbzY/FYNC4L+q/bJGNeNsbzXHZZKepmfw3IOtD uzaA== X-Gm-Message-State: AOUpUlFBgy6eWAFYxguJ1mw/1LcZ7BJEQJcWlmTSe3QebXFkJeFXwLll cObZ6qNt1OjH35lnCf9BK7Dw4rP+IQvx+MnDBdIULjvXl5Vcu05/dGmbQE6KB7Zez8Hza5mwfWo MeOawlnJ6iBkyEzSWhUtX+1yLgfk6DjwhyxO4P5fUEKzBmH4ri3TPf02HLK9avJo/7XOU2lnIpb uXs3h/iFea8/KjLVJMOUQ= X-Google-Smtp-Source: AA+uWPwY65cJzMthfgiAaZVKof33zm27SVJj17ID5UGfl+NK5T9JqCRB6H/ENKH1X0VsVVb2ojq1bA== X-Received: by 2002:a1c:415:: with SMTP id 21-v6mr2934332wme.128.1533757640487; Wed, 08 Aug 2018 12:47:20 -0700 (PDT) Received: from [10.137.2.21] (static-84-42-175-93.net.upcbroadband.cz. [84.42.175.93]) by smtp.gmail.com with ESMTPSA id s10-v6sm2765706wmd.22.2018.08.08.12.47.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Aug 2018 12:47:19 -0700 (PDT) Subject: Re: memory leak when serializing TRUNCATE in reorderbuffer To: Peter Eisentraut , pgsql-hackers@lists.postgresql.org References: <66175a41-9342-2845-652f-1bd4c3ee50aa@2ndquadrant.com> <04cfcf19-1a43-5d85-918d-56a8620377c4@2ndquadrant.com> From: Tomas Vondra Message-ID: Date: Wed, 8 Aug 2018 21:47:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <04cfcf19-1a43-5d85-918d-56a8620377c4@2ndquadrant.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 08/08/2018 09:19 PM, Peter Eisentraut wrote: > On 20/06/2018 21:42, Tomas Vondra wrote: >> So I think we should fix and serialize/restore the OID array, just like >> we do for tuples, snapshots etc. See the attached fix. > > Yes please. > OK, will do. >> Another thing we should probably reconsider is where the relids is >> allocated - the pointer remains valid because we happen to allocate it >> in TopMemoryContext. It's not that bad because we don't free the other >> reorderbuffer contexts until the walsender exits anyway, but still. >> >> So I propose to allocate it in rb->context just like the other bits of >> data (snapshots, ...). Replacing the palloc() in DecodeTruncate() with >> something like: >> >> MemoryContextAlloc(ctx->reorder->context, >> xlrec->nrelids * sizeof(Oid)); >> >> should do the trick. > > It's not clear from the code comments which context would be the > appropriate one. > > More standard coding style would be to set the current memory context > somewhere, but I suppose the reorderbuffer.c code isn't written that way. > IMHO the cleanest way is to add a method like ReorderBufferGetChange, which does the allocation internally. That way the memory context choice is up to reorderbuffer, not decode.c. That's at least consistent with what the rest of decode.c does. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services