| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Andreas Pflug <pgadmin(at)pse-consulting(dot)de> | 
| Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>, Dave Page <dpage(at)vale-housing(dot)co(dot)uk> | 
| Subject: | Re: [HACKERS] For review: Server instrumentation patch | 
| Date: | 2005-08-13 13:57:44 | 
| Message-ID: | 6432.1123941464@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-patches | 
Andreas Pflug <pgadmin(at)pse-consulting(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2005-08-13 14:03:03 | Re: [HACKERS] For review: Server instrumentation patch | 
| Previous Message | William ZHANG | 2005-08-13 13:10:46 | Re: [BUGS] BUG #1815: ECPGdebug causes crash on Windows XP |