pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedExecForceStoreMinimalTuple leaks memory like there's no tomorrow
4+ messages / 3 participants
[nested] [flat]
Commits from this thread:
2019-04-19 88e6ad3054 Fix two memory leaks around force-storing tuples in slots.
* ExecForceStoreMinimalTuple leaks memory like there's no tomorrow
@ 2019-04-16 02:46 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 4+ messages in thread
From: Tom Lane @ 2019-04-16 02:46 UTC (permalink / raw)
To: Andres Freund <andres@anarazel.de>; +Cc: pgsql-hackers@lists.postgresql.org
Using HEAD,
create table t1 as select generate_series(1,40000000) id;
vacuum analyze t1;
explain select * from t1, t1 t1b where t1.id = t1b.id;
-- should indicate a hash join
explain analyze select * from t1, t1 t1b where t1.id = t1b.id;
... watch the process's memory consumption bloat. (It runs for
awhile before that starts to happen, but eventually it goes to
a couple of GB.)
It looks to me like the problem is that ExecHashJoinGetSavedTuple
calls ExecForceStoreMinimalTuple with shouldFree = true, and
ExecForceStoreMinimalTuple's second code branch simply ignores
the requirement to free the supplied tuple.
regards, tom lane
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: ExecForceStoreMinimalTuple leaks memory like there's no tomorrow
@ 2019-04-16 03:31 Michael Paquier <michael@paquier.xyz>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 4+ messages in thread
From: Michael Paquier @ 2019-04-16 03:31 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Andres Freund <andres@anarazel.de>; pgsql-hackers@lists.postgresql.org
On Mon, Apr 15, 2019 at 10:46:56PM -0400, Tom Lane wrote:
> create table t1 as select generate_series(1,40000000) id;
> vacuum analyze t1;
> explain select * from t1, t1 t1b where t1.id = t1b.id;
> -- should indicate a hash join
> explain analyze select * from t1, t1 t1b where t1.id = t1b.id;
>
> ... watch the process's memory consumption bloat. (It runs for
> awhile before that starts to happen, but eventually it goes to
> a couple of GB.)
>
> It looks to me like the problem is that ExecHashJoinGetSavedTuple
> calls ExecForceStoreMinimalTuple with shouldFree = true, and
> ExecForceStoreMinimalTuple's second code branch simply ignores
> the requirement to free the supplied tuple.
Open item added, as the root comes from 4da597ed.
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: ExecForceStoreMinimalTuple leaks memory like there's no tomorrow
@ 2019-04-19 02:04 Andres Freund <andres@anarazel.de>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 4+ messages in thread
From: Andres Freund @ 2019-04-19 02:04 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers@lists.postgresql.org
Hi,
On 2019-04-15 22:46:56 -0400, Tom Lane wrote:
> Using HEAD,
>
> create table t1 as select generate_series(1,40000000) id;
> vacuum analyze t1;
> explain select * from t1, t1 t1b where t1.id = t1b.id;
> -- should indicate a hash join
> explain analyze select * from t1, t1 t1b where t1.id = t1b.id;
>
> ... watch the process's memory consumption bloat. (It runs for
> awhile before that starts to happen, but eventually it goes to
> a couple of GB.)
>
> It looks to me like the problem is that ExecHashJoinGetSavedTuple
> calls ExecForceStoreMinimalTuple with shouldFree = true, and
> ExecForceStoreMinimalTuple's second code branch simply ignores
> the requirement to free the supplied tuple.
Thanks for finding. The fix is obviously easy - but looking through the
code I think I found another similar issue. I'll fix both in one go
tomorrow.
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: ExecForceStoreMinimalTuple leaks memory like there's no tomorrow
@ 2019-04-19 18:55 Andres Freund <andres@anarazel.de>
parent: Andres Freund <andres@anarazel.de>
0 siblings, 0 replies; 4+ messages in thread
From: Andres Freund @ 2019-04-19 18:55 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers@lists.postgresql.org
Hi,
On 2019-04-18 19:04:09 -0700, Andres Freund wrote:
> On 2019-04-15 22:46:56 -0400, Tom Lane wrote:
> > Using HEAD,
> >
> > create table t1 as select generate_series(1,40000000) id;
> > vacuum analyze t1;
> > explain select * from t1, t1 t1b where t1.id = t1b.id;
> > -- should indicate a hash join
> > explain analyze select * from t1, t1 t1b where t1.id = t1b.id;
> >
> > ... watch the process's memory consumption bloat. (It runs for
> > awhile before that starts to happen, but eventually it goes to
> > a couple of GB.)
> >
> > It looks to me like the problem is that ExecHashJoinGetSavedTuple
> > calls ExecForceStoreMinimalTuple with shouldFree = true, and
> > ExecForceStoreMinimalTuple's second code branch simply ignores
> > the requirement to free the supplied tuple.
>
> Thanks for finding. The fix is obviously easy - but looking through the
> code I think I found another similar issue. I'll fix both in one go
> tomorrow.
Pushed the combined fix for that. Thanks!
Greetings,
Andres Freund
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2019-04-19 18:55 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2019-04-16 02:46 ExecForceStoreMinimalTuple leaks memory like there's no tomorrow Tom Lane <tgl@sss.pgh.pa.us>
2019-04-16 03:31 ` Michael Paquier <michael@paquier.xyz>
2019-04-19 02:04 ` Andres Freund <andres@anarazel.de>
2019-04-19 18:55 ` Andres Freund <andres@anarazel.de>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox