Re: serverlog function (log_destination file)

> > 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.
>
> Thanks Tom. I wonder if we (the pgAdmin team) finally need to bite the
> proverbial bullet and write a helper daemon that can allow access to
> logs as well as config files and pg_ctl etc. as an optional extra
> component.

It would certainly make things a lot easier for the box admin if you did
this as extension functions in pg instead of a separate daemon (even if
these are not installed in pg by default, but have to be installed
manually. Better if they are included by default, of course, from the
easy-to-admin perspective). Then it's just one set of firewall rules,
one process to check if it's running, etc.

Specifically about the logs, I still think there is a lot of value to
being able to read the logs remotely even if you can't restart
postmaster. Looking at the server logs can help you debug the database
client (for example when the app won't give you the full error msg, but
it goes in the server log). It won't help you if it's a postmaster
problem (since you won't get to it), but there are a lot of other
situations where it will.
(This is, btw, how MSSQL does it at least - you can view the server log
remotely if the server starts. If not, you'll have to go to the log
viewer on the server)

//Magnus