On Thu, Aug 31, 2017 at 2:34 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Magnus Hagander <mag...@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. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
