Re: pgsql 8.1 instrumentation status

> -----Original Message-----
> From: Andreas Pflug [mailto:pgadmin(at)pse-consulting(dot)de]
> Sent: 29 August 2005 22:40
> To: Dave Page
> Cc: pgadmin-hackers
> Subject: Re: [pgadmin-hackers] pgsql 8.1 instrumentation status
>
> > - 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.

Exactly.

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

No, you didn't, but the overall opinion on on -hackers was different,
and it went in. Like it or not, we have to work with it. We cannot
afford to start forcing people to use configurations that they might not
want because they'll simply say 'sod this' and go an try another admin
package.

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

I have. The only argument you gave was 'what if someone copies the
cluster'. Well, in my experience it's far more likely that someone will
change the logfile name format.

Anyway, I'll point out again - this is irrelevant as we do not have any
functionality that this will break at present.

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

The worst that will happen with any sane feature that might be added, is
that an old logfile might not be deleted because it's mtime or ctime is
too recent. That's merely an inconvenience - no data will be lost.

Am I missing some other, more disasterous potential problem?

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

That was only an example. What if people change the prefix to match some
site specific detail, say 'devpostmaster-[whatever]'. That may well be
perfectly sensible in some situations. The bottom line is, it's a
documented feature of the server, so we must assume that some people
will have a legitimate use for it.

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

Maybe, but given the effort I put in, and Magnus put in to get the code
included in the server in as much of it's original form as possible, I'm
damned if I'm just going to take that route now 'because it's less
effort'.

BTW, dunno if you noticed, but the absolute path thing should be fixed
in CVS HEAD now, giving access to Logdir and Datadir as per the original
admin functions.

Regards, Dave.