Horton
Menu

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

Justin Pryzby <pryzby@telsasoft.com>

View thread
From: Justin Pryzby <pryzby@telsasoft.com>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Noah Misch <noah@leadboat.com>, pgsql-hackers@postgresql.org
Date: 2024-11-27T15:35:16Z
Lists: pgsql-hackers 
On Wed, Nov 27, 2024 at 04:33:25PM +0100, Peter Eisentraut wrote:
> 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?

Yes -- I'd already checked.

-- 
Justin

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()