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

Bruce Momjian wrote:

> 
> I don't see any reason to have a pattern though I suppose if you mix
> pgsql log files in with other log files it might be a problem.  One idea
> would be for the client-side program to do some processing like this:
> 
>     SELECT *
>     FROM dir_listing('/var/log') AS dir
>     WHERE dir LIKE 'pgsql_%'
> 
> or something like that where the client pulls apart the directory
> specifiction like this:
> 
>     log_dest = '/var/log/postgresql.log.%Y-%m-%d_%H%M%S'
> 
> You do something that splits the value into directory name and file name
> and removes every letter after %.
> 
>     /var/log
>     postgresql.log.%-%-%_%%%
> 
> Another idea is to allow filename wildcards in the listing so it
> becomes:
> 
>     SELECT *
>     FROM dir_listing('/var/log/postgresql.log.*-*-*_***') AS dir
> 
> While that is nice, it doesn't match the functionality of opendir so we
> are perhaps better with one that doesn't handle wildcards and we just do
> the wildcard processing in the WHERE clause.

Uh, this looks ugly.

How about
pg_logfile_list() RETURNS setof timestamp -- to list available logfiles
pg_logfile_filename(timestamp) to return filename for that logfile

and generic
pg_dir(wildcard_text)
pg_file_length(filename_text)
pg_file_read(filename_text, offs, len)
pg_file_write(filename_text, contents_text)
pg_file_delete(filename)

I'd like to have the logfile api straigt forward. I finally would like 
all server logging to go into a non-configurable DataDir subdirectory 
pg_log with filenames mangled by internal rules. Maybe it's a good idea 
to have the pid in the filename too, to detect postmaster restarts.

> 
> Once we do this there will not be any backend writing to those files.

Of course not, only the logging subprocess may write.

> (We will need the log subprocess pid in shared memory so backends can
> send signals to it.) 

Yes, because the inherited SysLoggerPID might become invalid in case the 
logger process crashes and is recreated.
 I am not sure how we will do file deletes but I
> think each backend will have to do the delete itself rather than try to
> pass the file name to the log process. 

Agreed.
 I think we will have to assume
> the log file names increase in ordering so we know which one is the
> current one.   I can't think if a cleaner way to communicate this to the
> backends except perhaps as you suggest as shared memory areas that
> contains the name, but we will need a lock so the backends don't read it
> while it is changing.  That would be a nice feature.

We can omit this, if we supply only a native function. In that case, 
it's up to the admin not to shoot himself into the foot.

> 
> Sorry to be dumping more work on you but I think this is a better
> directory to go for this feature.

Well that's the pain with you cvs committers guys :-)

Regards,
Andreas