Re: serverlog function (log_destination file)
От | Dave Page |
---|---|
Тема | Re: serverlog function (log_destination file) |
Дата | |
Msg-id | E7F85A1B5FF8D44C8A1AF6885BC9A0E4A83D@ratbert.vale-housing.co.uk обсуждение исходный текст |
Ответы |
Re: serverlog function (log_destination file)
|
Список | pgsql-hackers |
> -----Original Message----- > From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Tom Lane > Sent: 07 June 2004 14:30 > To: Andreas Pflug > Cc: PostgreSQL Development > Subject: Re: [HACKERS] serverlog function (log_destination file) > > Andreas Pflug <pgadmin@pse-consulting.de> writes: > > Hm, what I missed is that pg_ctl's -l parameter converts to > a simple > > stderr redirection, and it's hardly possible to find out > where it's going. > > This could be solved by a file log_destination option or a > > freopen(...,stderr) from a guc variable. > > Any such patch would be rejected, because it would break the > ability to pipe stderr into another program (such as > logrotate). And what of the syslog case? I see the problems with the existing mechanisms, but just to float an idea - what about adding a GUC variable that can be used to specify an amount of shared memory to use as a fifo area in which a copy of the log output is stored for return to clients that might want it (accessing it via internal functions)? Regards, Dave
В списке pgsql-hackers по дате отправления: