Re: valgrind on initdb

On 2018-11-07 09:37:37 -0500, Andrew Dunstan wrote:
> 
> On 11/7/18 9:11 AM, Tomas Vondra wrote:
> > 
> > On 11/7/18 2:47 PM, John Naylor wrote:
> > > On 11/7/18, Jesper Pedersen <jesper.pedersen@redhat.com> wrote:
> > > > Hi,
> > > > 
> > > > While looking at [1] (included in 23315.log) there are other warnings as
> > > > well.
> > > Perhaps it's worth revisiting to make debugging easier, but right now
> > > initdb.c has this comment:
> > > 
> > >   * Note:
> > >   *     The program has some memory leakage - it isn't worth cleaning it up.
> > > 
> > Maybe. I certainly don't think it's not worth the time merely for the
> > sake of fixing the memory leaks. The reasoning here is that initdb runs
> > for a short period of time (a couple of seconds, really), and the memory
> > gets released when the process exits. And the leaks are tiny in general
> > - a couple of bytes here and there. Had there been a massive memory leak
> > that would change the equation of course.
> > 
> 
> Yeah, I'm pretty sure I wrote that comment 15 or so years ago in the first C
> implementation of initdb. I don't think my opinion has changed much. We're
> talking about kilobytes, here, nothing massive.

Yea, I'm opposed to fixing this by manually doing lotsa pfrees. We don't
do that anywhere for memory-lifetime allocations, and it'd not actually
be useful.

I think if we ever make mcxt style memory management usable for
frontends, the story could be a bit different. I could e.g. see having
one statically initialized context that contains most/all program
lifetime allocations. But that'd be just a minor positive side-effect.

Greetings,

Andres Freund