Re: [PATCH v11] GSSAPI encryption support - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [PATCH v11] GSSAPI encryption support
Date
Msg-id CAB7nPqSwnVLci7mZ89K+oNig7QHTi9MLxYnefOmgM=Vpro96ag@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH v11] GSSAPI encryption support  (Robbie Harwood <rharwood@redhat.com>)
Responses Re: [PATCH v11] GSSAPI encryption support  (Robbie Harwood <rharwood@redhat.com>)
List pgsql-hackers
On Sat, Apr 2, 2016 at 7:34 AM, Robbie Harwood <rharwood@redhat.com> wrote:
> - Attempt to address a crash Michael is observing by switching to using
>   the StringInfo/pqExpBuffer management functions over my own code as
>   much as possible.  Michael, if this doesn't fix it, I'm out of ideas.

Nope, it doesn't.

>   Since I still can't reproduce this locally (left a client machine and
>   a process on the same machine retrying for over an hour on your test
>   case and didn't see it), could you provide me with some more
>   information on why repalloc is complaining?
>   Is this a low memory situation where alloc might have failed?

No, this is an assertion failure, and it seems that you are compiling
this code without --enable-cassert, without the switch the code
actually works.

>   What's your setup look like?

Just a simple Linux VM running krb5kdc with 386MB of memory, with
Postgres running locally as well.

>   That pointer looks like it's on the heap, is that correct?

appendBinaryStringInfo depends on palloc calls that allocate memory
depending on the memory context used. It looks that what's just
missing in your logic is a private memory context that be_gssapi_write
and be_gssapi_read can use to handle the allocation of the
communication buffers.
-- 
Michael



pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: improving GROUP BY estimation
Next
From: Kevin Grittner
Date:
Subject: Re: snapshot too old, configured by time