BUG #9551: Hang in State "authentication" Prevents Vacuum from Freeing Dead Rows

The following bug has been logged on the website:

Bug reference: 9551
Logged by: James Morton
Email address: jmorton(at)gmail(dot)com
PostgreSQL version: 9.1.11
Operating system: CentOS 5.10
Description:

Hi,

Recently, we've twice encountered a problem where connection will hang in
state "authentication." While these connections are hung in this state,
they seem to block autovacuum from freeing dead rows, quickly causing
heavily modified tables to bloat. These connections do not respond to a
SIGQUIT signal.

When this last happened, we captured a backtrace of the hung connection:

(gdb) bt
#0 0x00000030820e104e in __lll_lock_wait_private () from /lib64/libc.so.6
#1 0x00000030820d1bf7 in _L_lock_646 () from /lib64/libc.so.6
#2 0x00000030820d168a in __vsyslog_chk () from /lib64/libc.so.6
#3 0x00000030820d1a73 in __syslog_chk () from /lib64/libc.so.6
#4 0x00000000006dd6f1 in EmitErrorReport ()
#5 0x00000000006ddaf5 in errfinish ()
#6 0x0000000000623f6a in ProcessInterrupts ()
#7 0x000000000062439c in StatementCancelHandler ()
#8 <signal handler called>
#9 0x00000030820306f7 in kill () from /lib64/libc.so.6
#10 0x0000000000616d01 in ?? ()
#11 0x0000000000616e3f in handle_sig_alarm ()
#12 <signal handler called>
#13 0x00000030820d5eb5 in send () from /lib64/libc.so.6
#14 0x00000030820d1750 in __vsyslog_chk () from /lib64/libc.so.6
#15 0x00000030820d1a73 in __syslog_chk () from /lib64/libc.so.6
#16 0x00000000006dd6f1 in EmitErrorReport ()
#17 0x00000000006ddaf5 in errfinish ()
#18 0x0000000000583c57 in ?? ()
#19 0x0000000000583c81 in ?? ()
#20 0x00000000005858af in ClientAuthentication ()
#21 0x00000000006e9bb6 in InitPostgres ()
#22 0x000000000062609d in PostgresMain ()
#23 0x00000000005e9dfc in ?? ()
#24 0x00000000005eab81 in PostmasterMain ()
#25 0x000000000058e38e in main ()

>From the stack trace, it looked to us like the connections were blocked
writing to syslog. We attempted restarting syslog, but that had no affect
on the hung connections.

Our authentication method for the hung connection should have been MD5,
though we do have LDAP enabled for other users.