Re: pgsql 8.1 instrumentation status

From: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
To: "Andreas Pflug" <pgadmin(at)pse-consulting(dot)de>, "pgadmin-hackers" <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: pgsql 8.1 instrumentation status
Date: 2005-08-28 21:23:42
Message-ID: E7F85A1B5FF8D44C8A1AF6885BC9A0E4AC9CEB@ratbert.vale-housing.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

> -----Original Message-----
> From: pgadmin-hackers-owner(at)postgresql(dot)org
> [mailto:pgadmin-hackers-owner(at)postgresql(dot)org] On Behalf Of
> Andreas Pflug
> Sent: 28 August 2005 21:48
> To: pgadmin-hackers
> Subject: [pgadmin-hackers] pgsql 8.1 instrumentation status
>
> I've been testing the current status of instrumentation function
> integration in pgsql8.1 and found the result quite frustrating.

We should talk more - I've been looking at that! (thought you were on
Slony).

> Only pg_reload_conf and pg_postmaster_start_time (formerly
> pg_postmaster_starttime) are implemented in a way comparable to the
> admin package (pg_logfile_rotate does work now, when calling
> pg_rotate_logfile; this needed backend support that wasn't
> present in 8.0).

Yup.

> All other functions are either omitted completely, or
> stripped down to
> near or complete unusability:
> The file functions, if present at all, don't accept absolute
> paths, even
> if the log directory is addressed. pg_read_file isn't a
> replacement for
>
> pg_file_read for this reason.

No, just hit that. We knew absolute paths outside the data dir were
going to be rejected, but they seem to have gone further. They should be
allow if:

1) The path starts with $PGDATA
2) The path exactly matches one of the config files.

I would call this a bug. If you've got time to produce a simple patch,
I'll try to argue it in.

> pg_ls_dir lost its second bool parameter.
>
> pg_stat_file isn't implemented, although announced by Bruce.
> This makes
> pg_file_length impossible.

Yes it is. I've just been using it. Don't forget, Tom made it into a
procedure to allow things like SELECT
(pg_file_stat('pg_hba.conf')).size; to work

> Naming:
> While only an annoying source of unnecessary work, the example of
> pg_stat_file (if it would exist) shows how arbitrary the
> change of names
> is: it follows the pattern of pg_stat_% statistics functions.
>
> Consequently, only a small fraction of the 8.0 admin package will be
> obsoleted for 8.1.
>

No, only write, unllink and rename should now be needed, with a suitable
patch to fix the path issue.

>
> PS AFAICS we now could add pg_terminate_backend safely too, IIRC the
> on-exit lock tables cleanup is corrected now.

I'm pretty sure we won't argue that one in now. I think Tom will demand
more proof of proper testing.

Regards, Dave.

Responses

Browse pgadmin-hackers by date

  From Date Subject
Next Message svn 2005-08-28 21:44:38 SVN Commit by andreas: r4424 - trunk/pgadmin3/src/ui
Previous Message svn 2005-08-28 21:15:27 SVN Commit by dpage: r4422 - trunk/pgadmin3/xtra