Re: 12.1 not useable: clientlib fails after a dozen queries (GSSAPI ?)

Greetings,

On Fri, Jan 10, 2020 at 15:58 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > Ah-hah. Not sure if that was Robbie or myself (probably me, really,
> > since I rewrote a great deal of that code). I agree that the regression
> > tests don't test with very much data, but I tested pushing quite a bit
> > of data through and didn't see any issues with my testing. Apparently I
> > was getting pretty lucky. :/
>
> You were *very* lucky, because this code is absolutely full of mistakes
> related to incomplete reads, inadequate or outright wrong error handling,
> etc.

I guess so.. I specifically remember running into problems transferring
large data sets before I rewrote the code but after doing so it was
reliable (for me anyway...).

I was nearly done cleaning that up, when it sank into me that
> fe-secure-gssapi.c uses static buffers for partially-read or
> partially-encoded data. That means that any client trying to use
> multiple GSSAPI-encrypted connections is very likely to see breakage
> due to different connections trying to use the same buffers concurrently.

Ughhh. That’s a completely valid point and one I should have thought of.

I wonder whether that doesn't explain the complaints mentioned upthread
> from the Ruby folks.

No- the segfault issue has been demonstrated to be able to reproduce
without any PG code involved at all, and it also involved threads with only
one connection, at least as I recall (on my phone atm).

(be-secure-gssapi.c is coded identically, but there it's OK since
> any backend only has one client connection to deal with.)

Right... I actually wrote the backend code first and then largely copied
it to the front end, and then adjusted it, but obviously insufficiently as
I had been thinking of just the one connection that the backend has to deal
with.

Thanks!

Stephen