Обсуждение: serverlog function
For adminstrator's convenience, I'd like to see a function that returns the serverlog. Are there any security or other issues that should prevent me from implementing this? Regards, Andreas
Andreas Pflug <pgadmin@pse-consulting.de> writes:
> For adminstrator's convenience, I'd like to see a function that returns
> the serverlog.
What do you mean by "returns the serverlog"? Are you going to magically
recover data that has gone to stderr or the syslogd daemon? If so, how?
And why wouldn't you just go and look at the log file, instead?
regards, tom lane
Tom Lane wrote: >Andreas Pflug <pgadmin@pse-consulting.de> writes: > > >>For adminstrator's convenience, I'd like to see a function that returns >>the serverlog. >> >> > >What do you mean by "returns the serverlog"? Are you going to magically >recover data that has gone to stderr or the syslogd daemon? If so, how? >And why wouldn't you just go and look at the log file, instead? > > I'd like to see the serverlog even if I can't "go and look at the log file", because I don't have file access to the server. Regards, Andreas
Andreas Pflug wrote: > Tom Lane wrote: > >> Andreas Pflug <pgadmin@pse-consulting.de> writes: >> >> >>> For adminstrator's convenience, I'd like to see a function that >>> returns the serverlog. >>> >> >> >> What do you mean by "returns the serverlog"? Are you going to magically >> recover data that has gone to stderr or the syslogd daemon? > 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. Regards, Andreas
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?
regards, tom lane
Andreas Pflug wrote: > Tom Lane wrote: > > >Andreas Pflug <pgadmin@pse-consulting.de> writes: > > > > > >>For adminstrator's convenience, I'd like to see a function that returns > >>the serverlog. > >> > >> > > > >What do you mean by "returns the serverlog"? Are you going to magically > >recover data that has gone to stderr or the syslogd daemon? If so, how? > >And why wouldn't you just go and look at the log file, instead? > > > > > > I'd like to see the serverlog even if I can't "go and look at the log > file", because I don't have file access to the server. Understand. Unfortunately, we don't allow such functionality. The only solution I can think of is to use syslog and send the logs to a machine where you do have access. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Tom Lane wrote: >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? > > > Might it be sensible to have pg_ctl write its log destination (if any) out to a file in the data dir? That plus the log_destination setting might provide enough info at least for some common cases. cheers andrew
Bruce Momjian wrote: >Andreas Pflug wrote: > > >>> >>> >>> >>I'd like to see the serverlog even if I can't "go and look at the log >>file", because I don't have file access to the server. >> >> > >Understand. Unfortunately, we don't allow such functionality. The only >solution I can think of is to use syslog and send the logs to a machine >where you do have access. > > > What I mean is not how to set up a log solution, but how to offer a convenient way for the windows spoiled admins who like to have a gui for all kind of stuff, and just wants to hit a button "show server log", regardless of server location and platform type. This is a request that was recommended for pgadmin3. AFAICS, we have some alternatives: - try to grab the currently created files/syslog/eventlog. Seems hard to do, because we'd depend on additional external tools. - redirect stderr to a postgresql.conf known file. Disadvantage: breaks piping. - maintain a sharedMem for the latest messages. Disadvantage: limited space, no access to older entries after postmaster restart. - additional log_destination "file". Disadvantage: Yet Another File besides the redirected stderr, but this seems a minor problem. Regards, Andreas
On Mon, Jun 07, 2004 at 16:06:53 +0200, Andreas Pflug <pgadmin@pse-consulting.de> wrote: > > AFAICS, we have some alternatives: You could also pipe the logs to a program that writes them to a table in the database. As long as the logging level wasn't set so high that inserting the log entries was logged. This should be a fairly simple program to write and could be provided to people that wanted to provide this feature for their server.
Andreas wrote: > > AFAICS, we have some alternatives: > - try to grab the currently created files/syslog/eventlog. > Seems hard to > do, because we'd depend on additional external tools. > - redirect stderr to a postgresql.conf known file. > Disadvantage: breaks > piping. > - maintain a sharedMem for the latest messages. Disadvantage: limited > space, no access to older entries after postmaster restart. > - additional log_destination "file". Disadvantage: Yet Another File > besides the redirected stderr, but this seems a minor problem. > Another alternative would be to add code to the admin tool to get the log via scp or a similar method. IMHO PostgreSQL is doing the right thing here by using the OS logging, and breaking that isn't a good idea when there are other ways to solve the problem.