Обсуждение: Re: serverlog function (log_destination file)

> -----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

"Dave Page" <dpage@vale-housing.co.uk> writes:
> ... 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)?

No, that's a nonstarter, because having the postmaster log into shared
memory means that the postmaster probably goes down too anytime a
backend crashes.  The shared area would have to have a mutual-exclusion
lock, and we definitely do not want the postmaster participating in any
lock protocols.

If I were trying to solve Andreas' problem, I'd pipe stderr to some
program that stores recent log output in a file that I know the location
of and can read from the hypothetical log-grabber function.  Actually I
don't see that there's any need to involve Postgres itself in this issue
at all --- seems like the only agreement needed is between the GUI and
the postmaster launching script about where the log file is.
        regards, tom lane

Tom Lane wrote:

>
>If I were trying to solve Andreas' problem, I'd pipe stderr to some
>program that stores recent log output in a file that I know the location
>of and can read from the hypothetical log-grabber function.  Actually I
>don't see that there's any need to involve Postgres itself in this issue
>at all --- seems like the only agreement needed is between the GUI and
>the postmaster launching script about where the log file is.
>  
>
What if there's no file access (e.g. only db admin, not sys admin, no 
file sharing, firewalled with only 5432 port access or similar)? I'd 
like a solution that needs just enabling in postgresql.conf and a button 
in pgadmin3 (probably phppgadmin would follow soon), on any platform.

Regards,
Andreas

Andreas Pflug <pgadmin@pse-consulting.de> writes:
> What if there's no file access

If you don't have any access to the machine then you are not really a
DBA, you only play one on TV.  You can't for example start and stop the
postmaster remotely.  So I don't have a lot of sympathy for the notion
that the logs have to be externally accessible, and none whatever for
the notion that this has to be possible in every configuration.
        regards, tom lane

Tom Lane wrote:

>Andreas Pflug <pgadmin@pse-consulting.de> writes:
>  
>
>>What if there's no file access
>>    
>>
>
>If you don't have any access to the machine then you are not really a
>DBA, you only play one on TV. 
>
However you may call me, I can think of many cases where I'd like to 
look at the server log, without wanting to change the configuration or 
start/stop the postmaster. The error message sent to the application 
might be lost, or an interference with another app might have caused 
troubles, so a collected log is fine for such cases, preferrably 
displayed by the same tool I'm tuning my queries with.

What you're telling me is that people should have a telnet session to 
the linux box and tail /usr/data/pgsql/serverlog, while they're working 
with comfortable gui tools otherwise. Sound dissatisfying.

The rhdb control center seems fine for a sysadmin-dbadmin who's going to 
install and reconfigure a machine, but I certainly don't want this for 
SQL centric work. And a Java GUI is a bad idea on win32 either...

Regards,
Andreas