Re: [PATCH v11] GSSAPI encryption support

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Robbie Harwood <rharwood(at)redhat(dot)com>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH v11] GSSAPI encryption support
Date: 2016-04-02 13:02:46
Message-ID: CAB7nPqSwnVLci7mZ89K+oNig7QHTi9MLxYnefOmgM=Vpro96ag@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Apr 2, 2016 at 7:34 AM, Robbie Harwood <rharwood(at)redhat(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2016-04-02 13:33:53 Re: snapshot too old, configured by time
Previous Message Dean Rasheed 2016-04-02 12:20:13 Re: improving GROUP BY estimation