| From: | "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Andreas Pflug" <pgadmin(at)pse-consulting(dot)de> |
| Cc: | "PostgreSQL Development" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: serverlog function (log_destination file) |
| Date: | 2004-06-07 13:44:53 |
| Message-ID: | E7F85A1B5FF8D44C8A1AF6885BC9A0E4A83D@ratbert.vale-housing.co.uk |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)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(at)pse-consulting(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2004-06-07 13:48:46 | Re: serverlog function (log_destination file) |
| Previous Message | Bruce Momjian | 2004-06-07 13:39:42 | Re: serverlog function |