Re: pgsql 8.1 instrumentation status

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

Dave Page wrote:
>
>
>
>>-----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).

Yes, but need those functions to work with logfiles etc.

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

logfiles may go somewhere else too.
>
> I would call this a bug. If you've got time to produce a simple patch,
> I'll try to argue it in.

I won't. A perfectly working and tightly restricted version is available
for more than a year now.

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

'k. pg_file_length may use it.

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

pg_logdir_ls...
I won't duplicate pgsql's formatting/interpreting code in pgadmin.

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

I'm certainly not talking about arguing to commit this to core, but to
support this in our package, which will be needed anyway, e.g. for
pg_logdir_ls.

Regards,
Andreas

In response to

Browse pgadmin-hackers by date

  From Date Subject
Next Message Dave Page 2005-08-28 22:59:32 Re: pgsql 8.1 instrumentation status
Previous Message svn 2005-08-28 21:44:38 SVN Commit by andreas: r4424 - trunk/pgadmin3/src/ui