Re: [HACKERS] For review: Server instrumentation patch - Mailing list pgsql-patches

From Tom Lane
Subject Re: [HACKERS] For review: Server instrumentation patch
Date
Msg-id 6432.1123941464@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] For review: Server instrumentation patch  (Andreas Pflug <pgadmin@pse-consulting.de>)
Responses Re: [HACKERS] For review: Server instrumentation patch
List pgsql-patches
Andreas Pflug <pgadmin@pse-consulting.de> writes:
> Bruce Momjian wrote:
>> Well, if they mix log files and non-log files in the same directory, we
>> would have to filter based on the log_filename directive in the
>> application, or use LIKE in a query.

> .. which is what pg_logdir_ls does. And it's robust against filenames
> that don't have valid dates too; imagine postgresql-2005-01-01_crash1.log.

The proposed version of pg_logdir_ls could not be called "robust" in any
way at all, considering that it fails as soon as you modify the log_filename
pattern.

I concur with Bruce that this is better left to the application side.
I don't see any basic functionality gain from doing it in the server.
The client code can look at log_filename and do the filtering just as
well (or badly) as it could possibly be done in the server.  Moreover,
having a restriction like "this doesn't work unless you use this
log_filename setting" feels more reasonable on the client side than
inside the server.

            regards, tom lane

pgsql-patches by date:

Previous
From: "William ZHANG"
Date:
Subject: Re: [BUGS] BUG #1815: ECPGdebug causes crash on Windows XP
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] For review: Server instrumentation patch