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

[patch] fe-connect.c doesn't handle EINTR correctly

From: David Ford <david+cert(at)blue-labs(dot)org>
To: pgsql-patches(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: [patch] fe-connect.c doesn't handle EINTR correctly
Date: 2002-03-16 05:44:25
Message-ID: 3C92DBB9.8050902@blue-labs.org (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Last year we had a drawn out discussion about this and I created a patch 
for it.  I never noticed that the patch didn't go in until I installed 
7.2 the other day and realised that fe-connect.c never was fixed.

Here is the patch again.  It is against CVS 3/16/2002.  This time I only 
rewrote the connect procedure at line 912, I leave it up to the regular 
hackers to copy it's functionality to the SSL procedure just below it.

In summary, if a software writer implements timer events or other events 
which generate a signal with a timing fast enough to occur while libpq 
is inside connect(), then connect returns -EINTR.  The code following 
the connect call does not handle this and generates an error message. 
 The sum result is that the pg_connect() fails.  If the timer or other 
event is right on the window of the connect() completion time, the 
pg_connect() may appear to work sporadically.  If the event is too slow, 
pg_connect() will appear to always work and if the event is too fast, 
pg_connect() will always fail.

David


Attachment: fe-connect.c-EINTR.diff
Description: text/plain (2.1 KB)

Responses

pgsql-hackers by date

Next:From: Vadim MikheevDate: 2002-03-16 06:04:09
Subject: Re: [BUGS] Bug #613: Sequence values fall back to previously chec
Previous:From: Greg CopelandDate: 2002-03-16 04:35:27
Subject: Re: User Level Lock question

pgsql-patches by date

Next:From: Christopher Kings-LynneDate: 2002-03-17 08:28:15
Subject: Add regression tests for ADD PRIMARY KEY
Previous:From: Alvaro HerreraDate: 2002-03-16 01:59:32
Subject: docbook.m4

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