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
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
