Andreas Pflug wrote:
> 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
I don't assume people using psql will care about the current log files ---
it would be something done in C or another application language. Aren't
the file names already ordered based on their file names, given the
default pattern, postgresql-%Y-%m-%d_%H%M%S.log?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
