Re: [PATCHES] serverlog rotation/functions - Mailing list pgsql-hackers

From Andreas Pflug
Subject Re: [PATCHES] serverlog rotation/functions
Date
Msg-id 40F63A9E.2070905@pse-consulting.de
Whole thread Raw
In response to Re: [PATCHES] serverlog rotation/functions  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: [PATCHES] serverlog rotation/functions  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Bruce Momjian wrote:
> 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.
> 

OK, next round.

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

If logfiles are located using directory listings, this would mean we 
should have well-known filename patterns instead of the current template 
stuff. So only the serverlog directory name would be selectable, if that  makes still sense (I'd opt to drop that).

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

We'd better have distinct functions. The current is for reading large 
chunks of data without interpretation of contents, and dir listing might  need tweaking for win32.
Now I wonder if it's better to have generic superuser-only functions for 
list/read/write/delete (this would enable client-side editing of 
postgresql.conf), or tie the functions to logfiles only (in which case 
the logfile functions shouldn't use filenames but logfile timestamps).

I still believe the log process should write the current logfile 
filename to shared-mem (write-only), so backends can prevent deleting it.


> 
> So, we have:
> 
>     o   use pipe and dup to copy stdout and stderr to your
>         postmaster child
>     o   new guc variables to specify log destination and rotation times
>     o   a server-side function to force a log rotate
>     o   API to list a directory and show file contents

I'll start on the log process.

Regards,
Andreas




pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Point in Time Recovery
Next
From: Mark Kirkwood
Date:
Subject: Re: Point in Time Recovery