Re: [HACKERS] For review: Server instrumentation patch

Bruce Momjian wrote:

>> BTW, it surprised me that one of the functions (don't remember
>> which one) expected the log files to be named in a very specific
>> fashion.  So there's no flexibility for changing the log_prefix.
>> Probably it's not so bad, but strange anyway.  Is this for
>> "security" reasons?

The logger subprocess patch originally didn't allow changing the the
logfile name pattern, to make sure it can be interpreted safely at a
later time. There's simply no way to mark the file with a timestamp
without the risk of it being arbitrarily modified by file commands, thus
screwing up the order of logfiles. Later, there was the request to
alternatively append a timestamp instead of a date pattern, to use
apache logging tools that will probably access the logfiles directly
anyway. This ended up in the log_filename GUC variable.

>
> Righ, pg_logdir_ls() was the function.  My feeling is that the
> application has access to the log_directory and log_filename values
> and can better and move flexibly filter pg_ls_dir() on the client end
>  than we can do on the server. It just seemed like something that we
> better done outside the server.

Outside the server means pure SQL, if you don't want to drop psql as
client. So how would your query to display all all available _logfiles_
look like? You'd need to check for a valid date, besides interpreting
pg_strfime's patterns. Doesn't sound exactly like fun, but I'm keen to
see how your equivalent to

SELECT *, pg_file_length(filename) AS len
   FROM pg_logdir_ls

looks like.

Regards,
Andreas