OK, I talked to Tom about this patch and I understand the issues now.
I think the best solution will be to have the postmaster start a child
process that can read the guc variables and create a log file based on
it contents. The child would be responsible to create a new log file
every X seconds as specified in the postgresql.conf file.
Backends wishing to read the log file would call a function to list the
contents of a directory. We can do this by creating a generic backend
super-user-only function that can list the contents of any directory.
Then you would use an API to read a specific file, similar to the log
reading functions you already have. In fact, you could set up the API
so reading a directory would return a list of directory names so you
don't need a separate directory listing function. (Does your API return
file contents as one big text string or as lines. If you return it as
one big text string, the directory idea will not work and you will need
a separate function.)
So, we have:
o use pipe and dup to copy stdout and stderr to your postmaster childo new guc variables to specify log
destinationand rotation timeso a server-side function to force a log rotateo API to list a directory and show file
contents
With this functionality, you can have clients listing the log directory
and choosing the most recent log file or previous ones. You could even
configure it to remove old log files.
Both Tom and I believe this is a more generic and reliable solution.
---------------------------------------------------------------------------
Andreas Pflug wrote:
> Bruce Momjian wrote:
> >
> > Also there are no documenttion changes.
>
> Here are the missing docs, freshly created against cvs.
>
> Regards,
> Andreas
>
-- 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
