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.


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to