Robbie Harwood wrote: > Alvaro Herrera <alvhe...@2ndquadrant.com> writes:
> > It seems to me that the right solution for this is to create a new > > memory context which is a direct child of TopMemoryContext, so that > > palloc can be used, and so that it can be reset separately, and that it > > doesn't suffer from resets of other contexts. (I think Michael's point > > is that if those chunks were it a context of their own, you wouldn't > > need the pfrees but a MemCxtReset would be enough.) > > Hmm, that's also an option. I read Michael's point as arguing for > calloc()/free() rather than a new context, but I could be wrong. Yeah, if you weren't using stringinfos that would be an option, but since you are I think that's out of the question. > A question, though: it it valuable for the context to be reset()able > separately? If there were more than just these two buffers going into > it, I could see it being convenient - especially if it were for > different encryption types, for instance - but it seems like it would be > overkill? If two buffers is all, I think retail pfrees are fine. I haven't actually read the patch. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
