Re: [HACKERS] log_destination=file

2017-09-10 Thread Dmitry Dolgov
> On 7 September 2017 at 15:46, Dmitry Dolgov <9erthali...@gmail.com> wrote: > > It seems that for this particular workload it was about 20-25% slower.‚Äč Hmm...looks like I provided misleading data, sorry. The numbers from previous email are correct and I'm able to reproduce them, but surprisingly

Re: [HACKERS] log_destination=file

2017-09-08 Thread Dmitry Dolgov
> On 8 September 2017 at 01:32, Magnus Hagander wrote: > > 1. where was stderr actually sent? To the console, to /dev/null or to a file? To the console (but I can also try other options, although I'm not sure if it would have any impact). > 2. Could you run the same thing

Re: [HACKERS] log_destination=file

2017-09-07 Thread Magnus Hagander
On Thu, Sep 7, 2017 at 7:02 AM, Tom Lane wrote: > Dmitry Dolgov <9erthali...@gmail.com> writes: > >> On 31 August 2017 at 14:49, Tom Lane wrote: > >> pgbench with log_statement = all would be a pretty easy test case. > > > It seems that for this

Re: [HACKERS] log_destination=file

2017-09-07 Thread Tom Lane
Dmitry Dolgov <9erthali...@gmail.com> writes: >> On 31 August 2017 at 14:49, Tom Lane wrote: >> pgbench with log_statement = all would be a pretty easy test case. > It seems that for this particular workload it was about 20-25% slower. Ouch. That seems like rather a large

Re: [HACKERS] log_destination=file

2017-09-07 Thread Dmitry Dolgov
Hi > On 31 August 2017 at 14:49, Tom Lane wrote: >> 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

Re: [HACKERS] log_destination=file

2017-09-01 Thread Magnus Hagander
On Fri, Sep 1, 2017 at 6:44 PM, Tom Lane wrote: > Magnus Hagander writes: > > On Fri, Sep 1, 2017 at 6:00 PM, Greg Stark wrote: > >> So what happens now with these messages? My understanding is that > >> they're missing from the CSV logs

Re: [HACKERS] log_destination=file

2017-09-01 Thread Tom Lane
Magnus Hagander writes: > On Fri, Sep 1, 2017 at 6:00 PM, Greg Stark wrote: >> So what happens now with these messages? My understanding is that >> they're missing from the CSV logs and are simply inserted into the >> text logs without any log_line_prefix? The

Re: [HACKERS] log_destination=file

2017-09-01 Thread Magnus Hagander
On Fri, Sep 1, 2017 at 6:00 PM, Greg Stark wrote: > On 31 August 2017 at 13:49, Tom Lane wrote: > > Magnus Hagander writes: > >> On Thu, Aug 31, 2017 at 2:34 PM, Tom Lane wrote: > > Yes, it's pretty important, because

Re: [HACKERS] log_destination=file

2017-09-01 Thread Greg Stark
On 31 August 2017 at 13:49, Tom Lane wrote: > Magnus Hagander writes: >> On Thu, Aug 31, 2017 at 2:34 PM, Tom Lane wrote: > Yes, it's pretty important, because of assorted stuff not-under-our- > control that doesn't know about ereport

Re: [HACKERS] log_destination=file

2017-08-31 Thread Tom Lane
Magnus Hagander writes: > On Thu, Aug 31, 2017 at 2:34 PM, Tom Lane 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

Re: [HACKERS] log_destination=file

2017-08-31 Thread Magnus Hagander
On Thu, Aug 31, 2017 at 2:34 PM, Tom Lane wrote: > Magnus Hagander 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. >

Re: [HACKERS] log_destination=file

2017-08-31 Thread Tom Lane
Magnus Hagander 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

[HACKERS] log_destination=file

2017-08-31 Thread Magnus Hagander
Attached is a very much VIP (AKA rough draft) for $subject. Right now we have two parameters controlling logging destination, and they work in interesting combinations: log_destination=stderr, logging_collector=off -> log to stderr (makes sense) log_destination=stderr, logging_collector=on ->