Magnus Hagander <mag...@hagander.net> writes: > On Thu, Aug 31, 2017 at 2:34 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> 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). Yes, it's pretty important, because of assorted stuff not-under-our- control that doesn't know about ereport and will just print to stderr anyway. Some examples: dynamic linker can't-resolve-symbol failure messages, glibc malloc corruption error messages, just about any external module in plperl or plpython. I don't find this to be negotiable. > Are you actually asking for a benchmark of if logging gets slower? Yes. > 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. pgbench with log_statement = all would be a pretty easy test case. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers