Re: 12.2: Howto check memory-leak in worker?
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter <pmc@citylink.dinoex.sub.org>
Cc: Thomas Munro <thomas.munro@gmail.com>,
Adrian Klaver <adrian.klaver@aklaver.com>,
"pgsql-generallists.postgresql.org"
<pgsql-general@lists.postgresql.org>
Date: 2020-05-05T15:59:27Z
Lists: pgsql-general
Peter <pmc@citylink.dinoex.sub.org> writes: > On Tue, May 05, 2020 at 10:57:04AM +1200, Thomas Munro wrote: > ! * Once a minute, verify that postmaster.pid hasn't been removed or > ! * overwritten. If it has, we force a shutdown. > It is really hard to comment on this in a way that might not be > considered offensive, so lets put it that way: You all have seen > the Apollo-13 movie, so You know that a need to power-down as much > as possible may appear en-route, and in a situation where you have > lots of other issues, so what you need the least is things like > this getting in your way. Well, the choice we face is preventing somebody's disk from spinning down, versus preventing somebody else from completely corrupting their database. From where I sit that's not a difficult choice, nor one that I feel a need to let users second-guess. > Now concerning the memory leak: > That one was introduced with the work done on the GSSAPI encryption; > it goes away when setting 'hostnogssenc' in pg_hba. Oooh ... it looks like some of the encryption code paths have neglected to call gss_release_buffer. Will fix, thanks for the report! regards, tom lane
Commits
-
Fix severe memory leaks in GSSAPI encryption support.
- 46da7bf671c0 13.0 landed
- 987717d7c700 12.3 landed