Skip site navigation (1) Skip section navigation (2)

Re: libpq bug handling signals

From: "Warren W(dot) Gay VE3WWG" <ve3wwg(at)cogeco(dot)ca>
To: PostgreSQL mailing list <pgsql-interfaces(at)postgresql(dot)org>
Subject: Re: libpq bug handling signals
Date: 2002-08-17 16:20:15
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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

In response to

pgsql-interfaces by date

Next:From: Björn LundinDate: 2002-08-19 08:54:58
Subject: Re: determining if there's a transaction in progress
Previous:From: Bruce MomjianDate: 2002-08-17 12:19:35
Subject: Re: [INTERFACES] libpgtcl modifications

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group