Horton

Re: Getting better results from valgrind leak tracking

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2021-03-18T03:21:47Z
Lists: pgsql-hackers 
Andres Freund <andres@anarazel.de> writes:
> The most glaring case is the RelationInitTableAccessMethod() call in
> RelationBuildLocalRelation(). Seems like the best fix is to just move
> the MemoryContextSwitchTo() to just before the
> RelationInitTableAccessMethod().  Although I wonder if we shouldn't go
> further, and move it to much earlier, somewhere after the rd_rel
> allocation.

Yeah, same thing I did locally.  Not sure if it's worth working harder.

> There's plenty other hits, but I think I should get back to working on
> making the shared memory stats patch committable. I really wouldn't want
> it to slip yet another year.

+1, so far there's little indication that we're finding any serious leaks
here.  Might be best to set it all aside till there's more time.

			regards, tom lane

Commits

  1. Improve our support for Valgrind's leak tracking.

  2. Increment xactCompletionCount during subtransaction abort.

  3. Adjust design of per-worker parallel seqscan data struct

  4. Don't leak compiled regex(es) when an ispell cache entry is dropped.

  5. Don't leak malloc'd error string in libpqrcv_check_conninfo().

  6. Don't leak malloc'd strings when a GUC setting is rejected.

  7. Don't leak rd_statlist when a relcache entry is dropped.

  8. Don't run RelationInitTableAccessMethod in a long-lived context.