Greetings, On Fri, Jan 10, 2020 at 15:58 Tom Lane <t...@sss.pgh.pa.us> wrote:
> Stephen Frost <sfr...@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. Thanks! Stephen
