From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Robbie Harwood <rharwood(at)redhat(dot)com> |
Cc: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH v12] GSSAPI encryption support |
Date: | 2016-04-05 20:58:17 |
Message-ID: | 20160405205817.GA366676@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robbie Harwood wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-04-05 21:12:11 | Re: large regression for parallel COPY |
Previous Message | David Steele | 2016-04-05 20:39:48 | Re: [PATCH v12] GSSAPI encryption support |