From: | Kirill Reshke <reshkekirill(at)gmail(dot)com> |
---|---|
To: | Tomas Vondra <tomas(at)vondra(dot)me> |
Cc: | "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, 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-10-18 12:42:43 |
Message-ID: | CALdSSPgOzs2Dyp9jeTMZUyJyct4XMMZCNamndbpxL6W4Wq1TBw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi!
On Mon, 5 Aug 2024 at 20:05, Tomas Vondra <tomas(at)vondra(dot)me> wrote:
>
> 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.
+ 1, there is a memory leak.
>
>
> regards
>
> --
> Tomas Vondra
>
>
So, I did some testing, and it seems that the tuple returned by
`gistgetadjusted` inside `gist_check_page` is not being freed.
Trivial fix attached.
--
Best regards,
Kirill Reshke
Attachment | Content-Type | Size |
---|---|---|
v28-0014-Fix-memory-leak-in-gist_check_page.patch | application/octet-stream | 1.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Aleksander Alekseev | 2024-10-18 13:17:52 | Re: unicode test programs don't build with meson |
Previous Message | Stefan Fercot | 2024-10-18 12:39:26 | Re: Recovery of .partial WAL segments |