Re: Re: [HACKERS] WIP: Separate log file for extension

From: David Steele <david(at)pgmasters(dot)net>
To: Antonin Houska <ah(at)cybertec(dot)at>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [HACKERS] WIP: Separate log file for extension
Date: 2018-02-07 14:59:40
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hi Antonin,

On 1/10/18 5:38 PM, Tom Lane wrote:
> Antonin Houska <ah(at)cybertec(dot)at> writes:
>> After having read the thread on your patch I think that the reason you were
>> asked to evaluate performance was that your patch can possibly make syslogger
>> a bottleneck. In contrast, my patch does not prevent user from disabling the
>> syslogger if it (the syslogger) seems to cause performance issues.
> Just to clarify that: we know that in workloads that emit lots of log
> output, the log collector *already is* a bottleneck; there are reports
> that some people can't use it because it's too slow. See e.g. towards
> the end of this thread:
> and particularly the referenced thread from 2011. (I seem to recall other
> reports but didn't have much luck finding them.)
> I'm quite concerned by the proposed patch, and not even so much any
> performance issues; what bothers me is that it adds complexity into a
> portion of the system where we can ill afford it. Bugs in the logging
> mechanism compromise one's ability to have any faith in tracking down
> other bugs. The difficulty of reconfiguring the logger on the fly
> is another reason to not want more configuration options for it.
> On the whole, therefore, I'd just as soon not go there --- especially
> seeing that there's been little field demand for such features.

I think this feature would be useful, especially for an extension like
pgaudit. It's a request I hear fairly frequently.

However, there doesn't seem to be consensus that this is a viable
approach, so marked as Returned with Feedback for this CF.

This may be too invasive a feature to be a good fit for the last PG11 CF
in March but I hope you keep working on the idea.


In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2018-02-07 15:04:29 Re: update tuple routing and triggers
Previous Message Andres Freund 2018-02-07 14:54:05 Re: JIT compiling with LLVM v10.0