Обсуждение: valgrind on initdb

Hi,

While looking at [1] (included in 23315.log) there are other warnings as 
well.

I ran with

valgrind --leak-check=full --show-leak-kinds=all --gen-suppressions=all 
--suppressions=/path/to/postgresql/src/tools/valgrind.supp 
--time-stamp=yes --log-file=/tmp/valgrind/%p.log --trace-children=yes 
--track-origins=yes --read-var-info=yes initdb -D /tmp/pgsql --no-clean 
--no-sync --no-locale 2>&1 | tee /tmp/valgrind/initdb.log

[1] 
https://www.postgresql.org/message-id/cb062f4d-55b8-28be-b55f-2e593a3b3755%40redhat.com

Best regards,
  Jesper

On 11/7/18 8:08 AM, Jesper Pedersen wrote:
> While looking at [1] (included in 23315.log) there are other warnings as 
> well.
> 

On 77366d90.

Best regards,
  Jesper

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.

-John Naylor

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.

cheers

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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.


cheers


andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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