Port Bug Report: When you scan the 5432 TCP port of Postmaster process, it hangs

============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================

Your name : Philippe LANGLOIS
Your email address : phil(at)qualys(dot)com

Category : runtime: back-end
Severity : critical

Summary: When you scan the 5432 TCP port of Postmaster process, it hangs

System Configuration
--------------------
Operating System : Linux www 2.2.3 #2 mer mar 10 19:11:40 CET 1999 i686 unknown

PostgreSQL version : 6.4.2

Compiler used : Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.7.2.3/specs,
gcc version 2.7.2.3

Hardware:
---------
Linux www 2.2.3 #2 mer mar 10 19:11:40 CET 1999 i686 unknown

Versions of other tools:
------------------------
GNU Make version 3.76.1
flex version 2.5.4

--------------------------------------------------------------------------

Problem Description:
--------------------
Hi,

First of all, i want to tell you that your work is really wonderful and i
much prefer to use PostgreSQL than Oracle.

Here is a behaviour which seems to me weird:
===========================================
When "postmaster" receives a TCP connection to its port (5432),
and then the connection is immediately closed, "postmaster" seems then
to stop processing new incoming connections.

Example:
> psql bcheck # Connection on the local base "bcheck"
[...normal connection...]
> nmap -g 20 -sS -P0 -F 127.0.0.1 # Local port scan
[...normal results of the portscan...]
> psql bcheck # psql doesn't display anything and
hangs.

Implication:
Potential denial of service problem.

--------------------------------------------------------------------------

Test Case:
----------
Full details:
- We're using version 6.4.2 of Postgres
- We're using tcp connectivity (port 5432)

------------ Step 1: Who is managing tcp port 5432 ? ------------
[root(at)localhost /tmp]# fuser -v -n tcp 5432/tcp

USER PID ACCESS COMMAND
5432/tcp postgres 7987 f.... postmaster

------------ Step 2: Let's look at this process ------------
strace -p 7987 # tracing of the postmaster process

------------ Step 3: Let's connect normally to it ------------
(user(at)localhost 601)psql bcheck
Welcome to the POSTGRESQL interactive sql monitor:
Please read the file COPYRIGHT for copyright terms of POSTGRESQL

type \? for help on slash commands
type \q to quit
type \g or terminate with semicolon to execute query
You are currently connected to the database: bcheck

bcheck=> \q

------------ Step 4: Look the normal trace ------------

[...normal trace of the beginning of connection...]
--- SIGCHLD (Child exited) ---
wait4(-1, [WIFEXITED(s) && WEXITSTATUS(s) == 0], WNOHANG, NULL) = 8004
semget(5432014, 0, 0) = 4608
semctl(4608, 0, IPC_RMID, 0xbffff864) = 0
sigaction(SIGCHLD, {0x80bffe4, [], 0x32}, {0x80bffe4, [], SA_STACK|SA_RESTART|SA_INTERRUPT|SA_ONESHOT|0x7fff818}) = 0
wait4(-1, 0xbffff8c0, WNOHANG, NULL) = -1 ECHILD (No child processes)
sigreturn() = ? (mask now [])
sigprocmask(SIG_SETMASK, [], NULL) = 0
select(5, [3 4], [], NULL, NULL

[We are back waiting with the select, good]

------------ Step 5: The beast, let's portscan my ------------
(user(at)localhost 608)nmap -g 20 -sS -P0 -F 127.0.0.1

Starting nmap V. 2.08 by Fyodor (fyodor(at)dhp(dot)com, www.insecure.org/nmap/)
Interesting ports on localhost (127.0.0.1):
Port State Protocol Service
21 open tcp ftp
80 filtered tcp http
111 filtered tcp sunrpc
514 open tcp shell
515 open tcp printer
5432 open tcp postgres
6000 open tcp xterm

Nmap run completed -- 1 IP address (1 host up) scanned in 1 second

------------ Step 6: Let's now look at the trace ------------
) = 1 (in [3])
sigprocmask(SIG_BLOCK, [CHLD], []) = 0
accept(3, 0x8165d30, [110]) = -1 ECONNRESET (Connection reset by peer)
write(2, "ERROR: postmaster: StreamConnec"..., 71) = 71
kill(7987, SIGQUIT) = 0
--- SIGQUIT (Quit) ---
getpid() = 7987
sigreturn() = ? (mask now [CHLD])
pause(

>>>>> Woooops... why postmaster is locked into this 'pause()' ?

------------ Step 7: ------------
>>>>> All subsequent connections are pending and no processing is done...

(vitamin(at)localhost 609)psql bcheck
[It hangs here and there's no output on the trace]

--------------------------------------------------------------------------

Solution:
---------

--------------------------------------------------------------------------