Unix Technical Forum

Re: pgsql 8.1 instrumentation status

This is a discussion on Re: pgsql 8.1 instrumentation status within the pgsql Interfaces Pgadmin Hackers forums, part of the PostgreSQL category; --> > -----Original Message----- > From: Andreas Pflug [mailto gadmin@pse-consulting.de] > Sent: 29 August 2005 10:21 > To: Dave Page ...


Go Back   Unix Technical Forum > Database Server Software > PostgreSQL > pgsql Interfaces Pgadmin Hackers

Register FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 04-17-2008, 05:29 PM
Dave Page
 
Posts: n/a
Default Re: pgsql 8.1 instrumentation status



> -----Original Message-----
> From: Andreas Pflug [mailtogadmin@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?
- 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.
- Virtually identical results can be achieved using ctime or mtime from
pg_stat_file with pg_dir_ls (as I think Bruce suggested).

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

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

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

Regards, Dave.

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #2 (permalink)  
Old 04-17-2008, 05:29 PM
Andreas Pflug
 
Posts: n/a
Default Re: pgsql 8.1 instrumentation status

Dave Page wrote:
>
>
>
>>-----Original Message-----
>>From: Andreas Pflug [mailtogadmin@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

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On
Forum Jump


All times are GMT. The time now is 08:45 AM.


Powered by vBulletin® Version 3.6.5
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
SEO by vBSEO 3.2.0
www.UnixAdminTalk.com