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

FE/BE protocol oddity

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: FE/BE protocol oddity
Date: 2001-07-05 19:49:18
Message-ID: Pine.LNX.4.30.0107052146400.677-100000@peter.localdomain (view raw or flat)
Thread:
Lists: pgsql-hackers
[Repost from July 1.  Hasn't made it to the list yet.]

The description of the FE/BE protocol says:

| The postmaster uses this info and the contents of the pg_hba.conf file
| to determine what authentication method the frontend must use. The
| postmaster then responds with one of the following messages:
[...]
| If the frontend does not support the authentication method requested by
| the postmaster, then it should immediately close the connection.

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.

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.  I see the JDBC
driver goes through troubles to make the same mistake.

In current sources the backends do the authentication and use the pqcomm.c
functions for communication, but those aren't that happy about the early
connection close:

  pq_recvbuf: unexpected EOF on client connection
  FATAL 1:  Password authentication failed for user 'peter'
  pq_flush: send() failed: Broken pipe

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.

Should I fix libpq to follow the docs in this and on the server's end make
anything that's not either a connection close or a valid authentication
response as "unexpected EOF"?  That way old clients would produce a bit of
noise in the server log.

Does anyone know how the ODBC and JDBC drivers handle this situation?

Btw., is recv(sock, x, 1, MSG_PEEK) == 0 an appropriate way to check for a
closed connection without reading anything?

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


Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2001-07-05 20:30:40
Subject: Solaris source code
Previous:From: Mikheev, VadimDate: 2001-07-05 19:46:44
Subject: RE: Re: Buffer access rules, and a probable bug

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