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

Re: FE/BE protocol oddity

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FE/BE protocol oddity
Date: 2001-07-05 20:38:03
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> However, libpq doesn't do that.  Instead, it leaves the connection open
> and returns CONNECTION_BAD to the client.  The client would then
> presumably call something like PQfinish(), which sends a Terminate message
> and closes the connection.  This happened to not confuse the <=7.1
> postmasters because they were waiting for 4 bytes and treated the early
> connection close appropriately.

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.

> On this occasion let me also point out that

>     pqPuts("X", conn);

> is not the way to send a single byte 'X' to the server.

Huh?  Oh, the trailing null byte.  You're right, it should be
	pqPutnchar("X", 1, conn);

> So I figured I would sneak in a check for connection close before reading
> the authentication response in the server, but since the frontends seems
> to be doing what they want I don't really know what to check for.

Seems reasonable, with the understanding that we'll still generate the
silly log messages when talking to an old client.  However...

> 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?  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...

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Naomi WalkerDate: 2001-07-05 21:03:31
Subject: Re: Solaris source code
Previous:From: Bruce MomjianDate: 2001-07-05 20:30:40
Subject: Solaris source code

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