Re: [HACKERS] [PATCHES] Patch to log usage of temporary files

On Thu, 2007-01-11 at 12:35 -0500, Tom Lane wrote:
> "Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> >> Tom Lane wrote:
> >>> The TRACE is in the wrong place no? I thought it was going to be after
> >>> the stat() operation so it could pass the file size.
>
> > We had that discussion already. If you only pass it after the stat()
> > then you cannot use DTrace, except when you already get a message in the
> > log and therefore don't need DTrace.
>
> We may have had the discussion, but apparently you didn't follow it :-(.

My apologies.

> > You can't say we don't have many probes so we won't add one. There never
> > will be many if we do that - its a circular argument.
>
> I think the real criterion has to be "is this probe useful to
> developers?". I'm entirely uninterested in adding probes that are
> targeted towards DBAs, as this one would have been --- if we think
> there's a problem that a DBA would have, we need to offer a more
> portable solution than that. Which we did, in the form of a logging
> option, which makes the DTrace probe pretty useless anyway.

Well, you know my major objection to including DTrace was all to do with
portability. I'm happy that the way its been implemented allows other
solutions to take advantage of the trace points also.

We're working on 8.3 now and by the time that is delivered and perhaps
for 2 years hence, i.e. Aug 2009, the software will be in production
use. In that period, DTrace will have been ported more widely and I'm
hearing that some kind of user space solution for Linux will mature in
that time also. If that isn't true then I'll be more interested in some
custom tracing solutions built around the PG_TRACE macro concept.

My thought is to provide both a log-based trace solution as has been
done, plus a hook for PG_TRACE (not just DTrace) at the same time. i.e.
each time we enhance the logging infrastructure, take the time to place
a trace point there also.

Theologically, we both know we see things differently on the DBA v
Developer discussion. The only point I would make is that the more
information you give the DBA, the more comes back to you as a Developer.
You, personally, could not possibly have interacted with as many server
set-ups required to highlight the problems and issues you address. It's
only because of the info provided by the existing system that you're
able to make headway with rare optimizer problems. My perspective is
that if you help the DBA you also help the Developer; if you help the
Developer only, then the Developer's information is also inevitably
restricted. The tip says "EXPLAIN ANALYZE is your friend". It's right,
and it isn't just talking to DBAs. My feeling is that this is true for
all tools/trace mechanisms.

I'd rather be sent the info than have to go do it myself on an
individual basis. Indirect access isn't the best way, but we harvest a
much wider range of information that way.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com