pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: pgsql-hackers@lists.postgresql.org
Subject: Re: memory leak when serializing TRUNCATE in reorderbuffer
Date: Wed, 8 Aug 2018 21:47:17 +0200
Message-ID: <a6e5cf90-bee9-8b57-5f13-bed59cf6014f@2ndquadrant.com> (raw)
In-Reply-To: <04cfcf19-1a43-5d85-918d-56a8620377c4@2ndquadrant.com>
References: <66175a41-9342-2845-652f-1bd4c3ee50aa@2ndquadrant.com>
	<04cfcf19-1a43-5d85-918d-56a8620377c4@2ndquadrant.com>



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




view thread (5+ messages)  latest in thread

Message-ID: <a6e5cf90-bee9-8b57-5f13-bed59cf6014f@2ndquadrant.com>
Permalink:  ../a6e5cf90-bee9-8b57-5f13-bed59cf6014f@2ndquadrant.com/
Also on:    postgresql.org/message-id/a6e5cf90-bee9-8b57-5f13-bed59cf6014f@2ndquadrant.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tomas.vondra@2ndquadrant.com, peter.eisentraut@2ndquadrant.com, pgsql-hackers@lists.postgresql.org
  Subject: Re: memory leak when serializing TRUNCATE in reorderbuffer
  In-Reply-To: <a6e5cf90-bee9-8b57-5f13-bed59cf6014f@2ndquadrant.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox