Re: pgsql 8.1 instrumentation status - Mailing list pgadmin-hackers

From Andreas Pflug
Subject Re: pgsql 8.1 instrumentation status
Date
Msg-id 431380C1.4060809@pse-consulting.de
Whole thread Raw
In response to Re: pgsql 8.1 instrumentation status  ("Dave Page" <dpage@vale-housing.co.uk>)
List pgadmin-hackers
Dave Page wrote:
>
>
>
>>-----Original Message-----
>>From: Andreas Pflug [mailto:pgadmin@pse-consulting.de]
>>Sent: 29 August 2005 10:21
>>To: Dave Page
>>Cc: pgadmin-hackers
>>Subject: Re: [pgadmin-hackers] pgsql 8.1 instrumentation status
>>
>>
>>I won't implement date interpretation in the client, full stop.
>
>
> Seriously Andreas, you need to get over this annoyance about these
> functions not getting in as is. It's not healthy, and is only hurting
> you and the end users who might miss out on features. I realise the end
> result wasn't exactly what you wanted, but sometimes we just have to
> compromise, otherwise we won't get anywhere at all.
>
> Please, let's move on and make things work with what we have.
>
>
>>You, as well as all others complaining about pg_logdir_ls, fail to
>>explain how a query like
>>select pg_file_unlink(filename) FROM pg_logdir_ls
>>where filetime < now() - '10 days'::interval
>>should work reliably. Try it with an alternate implementation, in the
>>presence of "bizarre filenames"!
>>
>
>
> There are various reasons for this, including:
>
> - None of our code does that, so it is a non-issue at the moment.
> - There is no pg_file_unlink in the server, so why should the
> pgsql-hackers care about making it easy to use?

This condenses the problem. They don't care.

> - pg_logdir_ls only worked with log_filename set to a specific value.
> You know as well as anyone that this is not good software design.

I never intended to open this to configuration. MSSQL doesn't offer this
too.

> - Virtually identical results can be achieved using ctime or mtime from
> pg_stat_file with pg_dir_ls (as I think Bruce suggested).

No, not reliably. See the archives.

> If you are not happy with this, please let me know and I will fix the
> logfile viewer for 8.1.

This is not fixing, this is working around.
pg_logdir_ls works reliably or not at all, if you take the break option
(editing log_filename). All other proposals can be damaged in less
obvious ways.

>>This logfile configuration stuff is a bummer. Anybody who changes it
>>will probably use his own logfile reader.
>
>
> Possibly, but not necessarily. What about people who rotate their logs
> daily for example? They might simply want to lose the unnecessary
> characters from the filenames.

Which would be really short sighted, and is error prone. When max
logfile size is reached, those people will be bitten.

>>I'll be committing a 8.1 version of the admin package soon,
>>which may be
>>switched over step by step to use core functions if applicable. For
>>now,  most of them do not deliver the same functionality as
>>present for 8.0.
>
>
> I already created an 8.1 admin pack and committed it to SVN. Currently
> it contains rename, write and unlink. If we need to add more, I'd like
> it to be because we really have no choice to get sane functionality,
> rather than just because we would prefer something work slightly
> differently.

Adapting the 8.0 admin package to 8.1 is much less effort than adapting
to the pgsql functions.

Regards,
Andreas

pgadmin-hackers by date:

Previous
From: svn@pgadmin.org
Date:
Subject: SVN Commit by dpage: r4426 - trunk/www/pgadmin3/cnt
Next
From: "Dave Page"
Date:
Subject: Re: pgsql 8.1 instrumentation status