Jan Wieck <janwi...@yahoo.com> writes: > On 12/20/2012 4:47 PM, Dimitri Fontaine wrote: >> Tom Lane <t...@sss.pgh.pa.us> writes: >>> The reason this fails is that you've got a half-megabyte source string, >>> and each of the 11000 plans that are due to be created from it saves >>> its own copy of the source string. Hence, 5500 megabytes needed just >>> for source strings. >>> >>> We could possibly fix this by inventing some sort of reference-sharing >>> arrangement (which'd be complicated and fragile) or by not storing the >>> source strings with the plans (which'd deal a serious blow to our >>> ability to provide helpful error messages). Neither answer seems >>> appealing.
> Don't all the plans result as a plan list from a multi-statement query > string, which was parsed into a query tree "list" and each single query > tree then planned? I don't think there is any way that a single one of > those trees (parse or plan) will be free'd separately. If that is true, > then proper usage of memory contexts would make reference counting > obsolete, even though all plans refer to the same copy. The issue is that a multi-statement string gives rise to multiple CachedPlanSources, which could be freed independently so far as plancache.c knows. (spi.c wouldn't actually attempt to do so.) So you'd really need reference counting, or else some explicit connection between the CachedPlanSources, neither of which seems exactly trivial to me. As of HEAD this particular complaint is moot anyway, because SPI_execute now goes through the "one-shot CachedPlan" facility, and so it makes no (zero) copies of the source string. It'd still be possible to hit the problem when trying to SPI_prepare a very-many-statement string, but I think the use case for that is pretty darn small. So I'm not excited about adding complication to fix it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers