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