Re: Amcheck verification of GiST and GIN

From: Tomas Vondra <tomas(at)vondra(dot)me>
To: "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
Cc: Alexander Lakhin <exclusion(at)gmail(dot)com>, Andrey Borodin <amborodin86(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Jose Arthur Benetasso Villanova <jose(dot)arthur(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Amcheck verification of GiST and GIN
Date: 2024-08-05 15:05:04
Message-ID: 9ff1e3fe-ada6-4b92-a3f9-a7753362323d@vondra.me
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

I've spent a bit more time looking at the GiST part as part of my
"parallel GiST build" patch nearby, and I think there's some sort of
memory leak.

Consider this:

create table t (a text);

insert into t select md5(i::text)
from generate_series(1,25000000) s(i);

create index on t using gist (a gist_trgm_ops);

select gist_index_check('t_a_idx', true);

This creates a ~4GB GiST trigram index, and then checks it. But that
gets killed, because of OOM killer. On my test machine it consumes
~6.5GB of memory before OOM intervenes.

The memory context stats look like this:

TopPortalContext: 8192 total in 1 blocks; 7680 free (0 chunks); 512 used
PortalContext: 1024 total in 1 blocks; 616 free (0 chunks); 408
used: <unnamed>
ExecutorState: 8192 total in 1 blocks; 4024 free (4 chunks); 4168 used
printtup: 8192 total in 1 blocks; 7952 free (0 chunks); 240 used
ExprContext: 8192 total in 1 blocks; 7224 free (10 chunks); 968 used
amcheck context: 3128950872 total in 376 blocks; 219392 free
(1044 chunks); 3128731480 used
ExecutorState: 8192 total in 1 blocks; 7200 free (0 chunks);
992 used
ExprContext: 8192 total in 1 blocks; 7952 free (0 chunks);
240 used
GiST scan context: 22248 total in 2 blocks; 7808 free (8
chunks); 14440 used

This is from before the OOM kill, but it shows there's ~3GB of memory is
the amcheck context.

Seems like a memory leak to me - I didn't look at which place leaks.

regards

--
Tomas Vondra

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Umar Hayat 2024-08-05 15:17:38 Re: psql client does not handle WSAEWOULDBLOCK on Windows
Previous Message Heikki Linnakangas 2024-08-05 14:41:21 Re: BlastRADIUS mitigation