Re: big text field -> message type 0x44

Поиск
Список
Период
Сортировка
От Tomas Berndtsson
Тема Re: big text field -> message type 0x44
Дата
Msg-id 80wumoojo3.fsf@junk.nocrew.org
обсуждение исходный текст
Ответ на Re: big text field -> message type 0x44  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: big text field -> message type 0x44  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> Tomas Berndtsson <tomas@nocrew.org> writes:
> > After it tries again, it always gets error from recv() for some reason
> > that I don't know. I also don't understand why errno is set to ENOTTY
> > at this point, that makes no sense at all.
> 
> Are you sure it is set?  Try setting errno=0 just before recv() (inside
> the retry loop).  Maybe recv() is neglecting to set it in this case.

Indeed you were right in this. But, if I added -D_REENTRANT to the
Makefile for libpq, it started to set it. If libpq should be thread
safe, I believe it should be compiled with -D_REENTRANT. 

When I did this, recv still returns error, but now sets errno to
EAGAIN, so pqReadData() returns 1, giving the same result as removing
the if-statement that does the try again thing. 

> > By skipping the trying again if-statement, pqReadData() will always
> > return proper data, and let the calling function deal with the fact
> > that there is more data to be read.
> 
> I have no confidence in this.  If the calling function comes back for
> more data, why wouldn't the recv() fail the same way?  A few more
> instructions in between shouldn't change its behavior, one would think.

No, I agree it sounds strange. I still haven't figured out why recv
fails after the goto, but not when calling the function again. 


Tomas


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Teodor Sigaev
Дата:
Сообщение: Re: contrib/ltree patches
Следующее
От: "Igor Georgiev"
Дата:
Сообщение: Re: Shrinkwrap Windows Product, any issues? Anyone? (postmaster windows shell)