Re: 12.1 not useable: clientlib fails after a dozen queries (GSSAPI?)
От | Peter |
---|---|
Тема | Re: 12.1 not useable: clientlib fails after a dozen queries (GSSAPI?) |
Дата | |
Msg-id | 20200110210337.GA9580@gate.oper.dinoex.org обсуждение исходный текст |
Ответ на | Re: 12.1 not useable: clientlib fails after a dozen queries (GSSAPI ?) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: 12.1 not useable: clientlib fails after a dozen queries (GSSAPI ?)
|
Список | pgsql-hackers |
On Fri, Jan 10, 2020 at 12:59:09PM -0500, Tom Lane wrote: ! [ redirecting to -hackers ] ! I modified the kerberos test so that it tries a query with a less ! negligible amount of data, and what I find is: ! ! * passes on Fedora 30, with either default or 1500 mtu ! * passes on FreeBSD 12.0 with default mtu ! * FAILS on FreeBSD 12.0 with mtu = 1500 So, it is not related to only VIMAGE @ R11.3, and -more important to me- it is not only happening in my kitchen. Thank You very much :) ! OTOH, I also find that there's some hysteresis in the behavior: ! once it's failed, reverting the mtu to the default setting doesn't ! necessarily make subsequent runs pass. It's really hard to explain ! that behavior if it's our bug. That's affirmative. Made me go astray a few times when trying to isolate it. On Fri, Jan 10, 2020 at 02:25:22PM -0500, Tom Lane wrote: ! Ah, I have it: whoever wrote pg_GSS_read() failed to pay attention ! to the fact that setting errno is a critical part of its API. ! Sometimes it returns -1 while leaving errno in a state that causes Wow, that's fast. My probability-guess this morning was either some hard-coded 8192-byte buffer, or something taking an [EWOULDBLOCK] for OK. Then I decided to not look into the code, as You will be much faster anyway, and there are other pieces of software where I do not have such a competent peer to talk to... Anyway, thanks a lot! PMc
В списке pgsql-hackers по дате отправления: