Stephen Frost <sfrost@snowman.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.
