Re: big text field -> message type 0x44 - Mailing list pgsql-hackers

From Tomas Berndtsson
Subject Re: big text field -> message type 0x44
Date
Msg-id 80wumoojo3.fsf@junk.nocrew.org
Whole thread Raw
In response to Re: big text field -> message type 0x44  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: big text field -> message type 0x44
List 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 by date:

Previous
From: Teodor Sigaev
Date:
Subject: Re: contrib/ltree patches
Next
From: "Igor Georgiev"
Date:
Subject: Re: Shrinkwrap Windows Product, any issues? Anyone? (postmaster windows shell)