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-29 21:40:17
Message-ID: 431380C1.4060809@pse-consulting.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

Dave Page wrote:
>
>
>
>>-----Original Message-----
>>From: Andreas Pflug [mailto:pgadmin(at)pse-consulting(dot)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

In response to

Browse pgadmin-hackers by date

  From Date Subject
Next Message Dave Page 2005-08-29 22:05:52 Re: pgsql 8.1 instrumentation status
Previous Message svn 2005-08-29 19:04:25 SVN Commit by dpage: r4426 - trunk/www/pgadmin3/cnt