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

  1. Fix severe memory leaks in GSSAPI encryption support.