Horton
Menu

Re: Don't overwrite scan key in systable_beginscan()

Peter Eisentraut <peter@eisentraut.org>

View thread
From: Peter Eisentraut <peter@eisentraut.org>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Noah Misch <noah@leadboat.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-11-27T15:33:25Z
Lists: pgsql-hackers 
On 26.11.24 14:56, Justin Pryzby wrote:
> Since 811af9786b, the palloc'd idxkey's seem to be leaking/accumulating
> throughout the command.
> 
> I noticed this on the master branch while running ANALYZE on partitioned
> table with 600 attributes, even though only 6 were being analyzed.
> 
> LOG:  level: 3; BuildRelationExtStatistics: 1239963512 total in 278 blocks; 5082984 free (296 chunks); 1234880528 used
> 
> Several indexes are being scanned many thousands of times.

Hmm, this patch inserts one additional palloc() call per 
systable_beginscan().  So it won't have much of an impact for isolated 
calls, but for thousands of scans you get thousands of small chunks of 
memory.

Does your test case get better if you insert corresponding pfree() calls?

A higher-level question would be whether there should be better memory 
management in the caller.  But it would be okay to address it with a 
pfree() as well, I think.

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix temporary memory leak in system table index scans

  2. Don't overwrite scan key in systable_beginscan()

  3. Replace gratuitous memmove() with memcpy()