On Thu, Aug 31, 2017 at 2:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes: > My understanding is that the main reason for this is that we cannot change > logging_collector without restarting postmaster, whereas we can change > log_destination.
Right, because the decision whether to redirect stdout/stderr can't be changed on the fly.
Right.
We could of course also say we only care about things generated by our ereport framework, in which case we don't need to redirect stderr and can just use a "regular pipe". But IIRC that's functionality we also specifically wanted (though I don't think I've ever needed it myself, presumably others have).
> My suggestion is we work around this by just always starting the logging > collector, even if we're not planning to use it.
Umm.... > Do people see an actual problem with that? I agree it's an extra round of > indirection there, but is that a problem? It would also cause one more > backgorund process to always be running, but again, is that really a > problem? The overhead is not exactly large.
You just made three assertions about "this isn't a problem" without providing any evidence in support of any of them. Maybe with some measurements we could have a real discussion.
Well, not entirely. The first two are questions "is this really a problem".
The overhead of an extra process certainly isn't much, I'm wiling to say that as an assertion.
The other two, less so, that's more question.
Are you actually asking for a benchmark of if logging gets slower? If so, could you suggest a workload to make an actual benchmark of it (where logging would be high enough that it could be come a bottleneck -- and not writing the log data to disk, but the actual logging). I'm not sure what a good one would be.
