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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "James L(dot) Morton" <jmorton(at)gmail(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #9551: Hang in State "authentication" Prevents Vacuum from Freeing Dead Rows
Date: 2014-03-14 21:54:38
Message-ID: 27619.1394834078@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"James L. Morton" <jmorton(at)gmail(dot)com> writes:
> We've added monitoring for this particular problem and saw this happen
> once more today. We noticed that this seems to correlate with a burst of
> log messages from auditd:
> ...
> When auditd exhausts its buffer, by default it begins logging to printk(),
> which in turn gets picked up by syslog. Perhaps this burst of messages is
> causing syslog to pause long enough to reach authentication_timeout? It
> seems odd, especially given that we have our Postgres syslog facility set
> to async.

Interesting. Yeah, you'd certainly imagine that it shouldn't wait if
properly configured, but that's what seems to be happening.

I've committed a fix (which will appear in next week's releases) that
prevents the recursive call of syslog() by delaying processing of the
authentication_timeout interrupt until elog() is done. That should fix
your problem as long as syslog's load-induced pause is transient.
However, if syslog() is getting wedged for some reason, you're still
going to have a stuck backend, because authentication_timeout won't
unwedge it.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Fujii Masao 2014-03-15 15:24:02 Re: BUG #9118: WAL Sender does not disconnect replication clients during shutdown
Previous Message James L. Morton 2014-03-14 20:54:01 Re: BUG #9551: Hang in State "authentication" Prevents Vacuum from Freeing Dead Rows