Re: [bug fix] Memory leak in dblink - Mailing list pgsql-hackers
From | Joe Conway |
---|---|
Subject | Re: [bug fix] Memory leak in dblink |
Date | |
Msg-id | 53A25347.1020401@joeconway.com Whole thread Raw |
In response to | Re: [bug fix] Memory leak in dblink (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: [bug fix] Memory leak in dblink
Re: [bug fix] Memory leak in dblink |
List | pgsql-hackers |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/18/2014 07:29 PM, Tom Lane wrote: > I wrote: >> I do see growth in the per-query context as well. I'm not sure >> where that's coming from, but we probably should try to find >> out. A couple hundred bytes per iteration is going to add up, >> even if it's not as fast as 8K per iteration. I'm not sure it's >> dblink's fault, because I don't see anything in dblink.c that is >> allocating anything in the per-query context, except for the >> returned tuplestores, which somebody else should clean up. > > I poked at this example some more, and found that the additional > memory leak is occurring during evaluation of the arguments to be > passed to dblink(). There's been a comment there for a very long > time suggesting that we might need to do something about that ... > > With the attached patch on top of yours, I see no leak anymore. I can confirm that -- rock solid with 1 million iterations. I assume that should not be back-patched though? On a side note, while perusing this section of code: 8<-------------------------- at dblink.c:1176 --------------------------/* make sure we have a persistent copy of the tupdesc*/tupdesc = CreateTupleDescCopy(tupdesc); /* check result and tuple descriptor have the same number of columns */if (nfields != tupdesc->natts) ereport(ERROR, (errcode(ERRCODE_DATATYPE_MISMATCH), errmsg("remote query result rowtype does not match " "the specified FROM clause rowtype"))); /* Prepare attinmeta for later data conversions */sinfo->attinmeta = TupleDescGetAttInMetadata(tupdesc); /* Create a new, empty tuplestore */oldcontext = MemoryContextSwitchTo(rsinfo->econtext->ecxt_per_query_memory);sinfo->tuplestore= tuplestore_begin_heap(true, false, work_mem);rsinfo->setResult= sinfo->tuplestore;rsinfo->setDesc = tupdesc;MemoryContextSwitchTo(oldcontext); 8<-------------------------- at dblink.c:1194 -------------------------- Shouldn't that CreateTupleDescCopy() happen in ecxt_per_query_memory? Joe - -- Joe Conway credativ LLC: http://www.credativ.us Linux, PostgreSQL, and general Open Source Training, Service, Consulting, & 24x7 Support -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTolNHAAoJEDfy90M199hlEN8QAIi3eq5D93Y4CqWWS8Uulqx1 jOBQUoLTwF7/CkYM0F+tGvX1QO1BAIDAxS6jwWXK/c9NqesVuS5tNwQcdrLb69Pm me4hQ2ZYtoCA4Y8SiFL0sOjUGuads2QEjhL3HUMQDBXTMjCpzamotIBGvYWu1OOe bf1VaY83bwGa6XvXYcfFFyqyUz+kMHvcM/Rq9Mj7pLrGT9Lqvec9RL/1FhFYamrI 2ewaKYC4htWXwk1xIvpDZtWTjLyv3BUl3X41BzPOecChWqXmYCpaPo+dR6V9LSm1 OxGFQL4Z3pM7VZDWk5FOj3vOFz1AJhWXEh8fyzlLKeDm7FFaApyf3rPLULBRO4sj 4C88lUdSbhzgTlMreq/wqBh2bKFmLGUA8M9sSwd+2DMc6QQQN0DWCgDtSZq/3Fwr Tc/0LWvHwh+/Tozx0kk0DxIQzS0BOsWHzjtOMwb1p3aLZXlG9FP5IrrPJlIyDOQK feVB9JNH5kGUFEU0OkGaqPaQy1lTVTizIA/FmTqV9QeJo2+vKSNPt2Ys4dM5jevo Tpp6ZAjvC6sAoIoWmvtazV5WOL7FwXwf8AQRJRgmh8JqHw4C2nZt9R+CNQqbGPa2 hxiTWi5EMufBmVOJeaEX867CUTLL6qzCtr/I2a2XZyMuPD5dQbS3l2MaYw1l2ucU o9x6G78hBR32xagpqPCE =LqzA -----END PGP SIGNATURE-----
pgsql-hackers by date: