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

Re: FE/BE protocol oddity

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FE/BE protocol oddity
Date: 2001-07-06 16:10:37
Message-ID: Pine.LNX.4.30.0107061802520.679-100000@peter.localdomain (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane writes:

> Good point.  Probably, PQfinish should only send the X message if the
> connection has gotten past the authentication stage.  A separate but
> also useful change would be to do immediate socket close on detecting
> auth failure, before returning to the client application.

Further investigation shows that all of this used to work correctly until
the infamous async connection patch.  The comment now reads:
(fe-connect.c)

	/*
	 * We used to close the socket at this point, but that makes it
	 * awkward for those above us if they wish to remove this socket from
	 * their own records (an fd_set for example).  We'll just have this
	 * socket closed when PQfinish is called (which is compulsory even
	 * after an error, since the connection structure must be freed).
	 */

I guess there is sort of a point there.  So I'm leaning towards adding a
"startup complete" flag somewhere in PGconn and simply fix up
closePGconn().

> > Btw., is recv(sock, x, 1, MSG_PEEK) == 0 an appropriate way to check for a
> > closed connection without reading anything?
>
> Seems a little risky as far as portability goes; is MSG_PEEK supported
> on BeOS, Darwin, Cygwin, etc?

Darwin is FreeBSD, so yes.  Cygwin says it supports recv() and MSG_PEEK is
trivial from there.  BeOS is going backrupt before the next release
anyway. ;-)  Seriously, in the worst case we'll get EINVAL.

> Might be better to fix the backend libpq routines to understand
> whether a connection-close event is expected or not, and only emit a
> complaint to the log when it's not.  Not sure how far such a change
> would need to propagate though...

Deep...

-- 
Peter Eisentraut   peter_e(at)gmx(dot)net   http://funkturm.homeip.net/~peter


In response to

Responses

pgsql-hackers by date

Next:From: J-P GuguyDate: 2001-07-06 16:16:47
Subject: amiint
Previous:From: Tom LaneDate: 2001-07-06 16:02:04
Subject: Re: Vacuum and Transactions

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