"James L. Morton" <jmorton@gmail.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