Thread: 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
Attachment
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