Обсуждение: log_destination
Is there a particular reason why we're not using the postgresql log collector in the debian packages, instead relying on pg_ctl -l, other than this being legacy from back before we even had the log collector? The reason I ask is that if we were using the log collector, it would be much easier to enable things like csv logging (wouldn't require a restart, for example)... If there isn't, any thoughts on changing it? :) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Re: Magnus Hagander 2013-03-05 <CABUevEyxztj1myF_sdpujeQrKzgfH+DAQd2sNfD-uxizw_9s8g@mail.gmail.com> > Is there a particular reason why we're not using the postgresql log > collector in the debian packages, instead relying on pg_ctl -l, other > than this being legacy from back before we even had the log collector? The problem is that errors during early startup (syntax errors in postgresql.conf, port unavailable, shmmax, whatever) will not go into the logging collector, but will still appear in the "pg_ctl -l" log file. Changing the default here would mean the admin had to check two log files if the server doesn't even start. pg_ctl -l ~/logfile -o '--logging-collector=on --log-destination=stderr --log-directory=pg_log --ffo=bla' start -> complains about "ffo" in ~/logfile Apart from that, I agree that the logging collector would be a lot nicer than the current logrotate rules with the "copytruncate" insanity. Christoph -- cb@df7cb.de | http://www.df7cb.de/
On 2013-03-06 11:05:58 +0100, Christoph Berg wrote: > Re: Magnus Hagander 2013-03-05 <CABUevEyxztj1myF_sdpujeQrKzgfH+DAQd2sNfD-uxizw_9s8g@mail.gmail.com> > > Is there a particular reason why we're not using the postgresql log > > collector in the debian packages, instead relying on pg_ctl -l, other > > than this being legacy from back before we even had the log collector? > > The problem is that errors during early startup (syntax errors in > postgresql.conf, port unavailable, shmmax, whatever) will not go into > the logging collector, but will still appear in the "pg_ctl -l" log > file. Changing the default here would mean the admin had to check two > log files if the server doesn't even start. > > pg_ctl -l ~/logfile -o '--logging-collector=on --log-destination=stderr --log-directory=pg_log --ffo=bla' start > > -> complains about "ffo" in ~/logfile > > Apart from that, I agree that the logging collector would be a lot > nicer than the current logrotate rules with the "copytruncate" > insanity. Both pg_ctl and the logging collector seem to open files in O_APPEND mode. So - provided we could figure out the correct filename - they could just log to the same file. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Re: Andres Freund 2013-03-06 <20130306102405.GL13803@alap2.anarazel.de> > Both pg_ctl and the logging collector seem to open files in O_APPEND > mode. So - provided we could figure out the correct filename - they > could just log to the same file. Probably impossible with %y-%m-%d style log files, because of the variable filename as such, and you will still get a stale/later unused fd pointing at the -l file after log switch. One solution could be not to use -l at all, which has the advantage that you get "I can't start" type errors at the console instead of the misleading "Server starting" message while in fact there are fatal errors waiting for you in the log. (On the other hand, you will probably still want a log file for those in non-interactive startups.) Christoph -- cb@df7cb.de | http://www.df7cb.de/
On Wed, Mar 6, 2013 at 11:37 AM, Christoph Berg <cb@df7cb.de> wrote: > Re: Andres Freund 2013-03-06 <20130306102405.GL13803@alap2.anarazel.de> >> Both pg_ctl and the logging collector seem to open files in O_APPEND >> mode. So - provided we could figure out the correct filename - they >> could just log to the same file. > > Probably impossible with %y-%m-%d style log files, because of the > variable filename as such, and you will still get a stale/later unused > fd pointing at the -l file after log switch. > > One solution could be not to use -l at all, which has the advantage > that you get "I can't start" type errors at the console instead of the > misleading "Server starting" message while in fact there are fatal > errors waiting for you in the log. (On the other hand, you will > probably still want a log file for those in non-interactive startups.) The RPMs use a separate "startup.log" (I think that's what it's called - or at least something similar). While not ideal, I think that's a fairly reasonable workaround for that issue. Startup issues aren't that common - and it's not unreasonable to look in "startup.log" if things don't start, I think... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On 3/6/13 6:02 AM, Magnus Hagander wrote: > The RPMs use a separate "startup.log" (I think that's what it's called > - or at least something similar). While not ideal, I think that's a > fairly reasonable workaround for that issue. Yes, that also matches what I've been doing.