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

From Bruce Momjian
Subject Re: [HACKERS] For review: Server instrumentation patch
Date
Msg-id 200508130133.j7D1XA116707@candle.pha.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  (Andreas Pflug <pgadmin@pse-consulting.de>)
Re: [HACKERS] For review: Server instrumentation patch  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
Andreas Pflug wrote:
> Bruce Momjian wrote:
>
> >
> >
> > I don't see how listing the log files relates to editing the confuration
> > files.
>
> Both are remote administration. While we've seen the discussion that one
> aspect (config file editing) should be performed in psql, you assume the
> other aspect (viewing the logfile) to be not interesting. Your
> argumentation doesn't seem consequent to me.

To me monitoring (logfiles) and configuration (postgresql.conf) are
different, but if I can make it easy to do both from psql, great.

I can see making postgresql.conf easy (SET GLOBAL), I am unsure about
making pg_hba.conf easy (and many feel that way), and I am not sure how
adding a log directory listing took makes things significantly easier to
monitor log files.

What I can imagine making things very easy is a readonly GUC that returns
the current log file name.  That I think should be in the backend, and I
can see a query that combines that with pg_read_file() that prints the
last 1000 bytes from the file.

    SELECT pg_read_file(t1.setting, -1000, 1000);
    FROM     (SELECT setting FROM pg_settings WHERE NAME = 'log_current_name') AS t1

> >>>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?
> >>
> >>The issue is _filtering_, not ordering. Since the log directory might be
> >>directed to a different location, non-pgsql logfiles might be there too.
> >>You'd probably won't expect to retrieve these files over a pgsql connection.
> >
> >
> > 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.

True, but that is more for the application.  I don't imagine a user
looking at that from psql would have a problem.

However, you asked for a query that looks like pg_ls_logdir() and here
it is:

    SELECT pg_ls_dir
    FROM    (
            SELECT pg_ls_dir(t1.setting)
            FROM     (SELECT setting FROM pg_settings WHERE NAME = 'log_directory') AS t1
        ) AS t2,
        (SELECT setting FROM pg_settings WHERE NAME = 'log_filename') AS t3
    WHERE  t2.pg_ls_dir LIKE regexp_replace(t3.setting, '%.*', '') || '%';

The one thing it doesn't do, as you mentioned, is check for valid dates,
but it is certainly more flexible than embedding something in the backend.

--
  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

pgsql-patches by date:

Previous
From: Andreas Pflug
Date:
Subject: Re: [HACKERS] For review: Server instrumentation patch
Next
From: Bruce Momjian
Date:
Subject: Re: PL/pgSQL: SELECT INTO EXACT