Re: libpq bug handling signals - Mailing list pgsql-interfaces

From Warren W. Gay VE3WWG
Subject Re: libpq bug handling signals
Date
Msg-id 3D5E77BF.3050108@cogeco.ca
Whole thread Raw
In response to libpq bug handling signals  ("Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>)
List pgsql-interfaces
Ignore this post. The problems were all mine. I checked the libpq
code it seems that it has done a good job at insulating the caller from
the vulgarities of EINTR and the like.

However, I would suggest that "errno be ignored" should be documented
in the libpq documentation, and that some note about EINTR handling
be added to make things clearer to the programmer using libpq.

Thanks, Warren.

Warren W. Gay VE3WWG wrote:

> I am experiencing problems with lo_write() (mostly), WRT to
> life after a signal has been handled.
>
> Socket I/O (read(2) for example) will return -1 and have errno = EINTR
> if it was blocked reading, and a signal was handled successfully while
> it was blocked. It appears that lo_write() should do something similar,
> but doesn't in practice ...
>
> If I clear errno=0 and then perform lo_write()s during which
> time a signal is received and handled, lo_write() will return -1
> indicating an error. However, upon checking the
> errno vallue, it indicates that no error has occurred (errno=0).
>
> However, if I set errno=EINTR prior to calling lo_write() each
> time, the same -1 is returned (after a signal) but now the
> errno = EINTR (as I had originally expected it should have been).
>
> It appears that EINTR processing is not correct or is incomplete in
> the libpq code. I have experienced similar weirdness in the
> operation of lo_lseek().
>
> Do I need to subsequently submit this as a bug somewhere?
>
> Thanks, Warren.


-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg





pgsql-interfaces by date:

Previous
From: "Warren W. Gay VE3WWG"
Date:
Subject: Transaction Abort State?
Next
From: Stephen Lee
Date:
Subject: libpq (Postgres 7.2.1) + MacOS X 10.1.5 problem