valgrind on initdb

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