Re: [PATCHES] serverlog rotation/functions

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