Hi all,
Sorry for arriving so late into the discussion.
I don't know if it's possible but it could be useful to have the text
of the query which required the creation of the temporary files as an
additional DETAIL line. At least, if it's possible to have it in this
part of the code.
Thoughts?
On Thu, 2007-01-11 at 12:35 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> 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
On Thu, 2007-01-11 at 12:37 -0500, Bruce Momjian wrote:
> The trace probe was incorrect
Yes, incomplete, no doubt. On that point you were 100% right to reject.
> and kind of at an odd place. I don't
> think we want to go down the road of throwing trace in everwhere, do we?
> I would like to se
On Thu, Jan 11, 2007 at 12:35:25PM -0500, Tom Lane wrote:
> 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 ha
Simon Riggs wrote:
> > > Also, I dunno much about DTrace, but I had the idea that you can't
> > > simply throw a PG_TRACE macro into the source and think you are done
> > > --- isn't there a file of probe declarations to add to? Not to mention
> > > the documentation of what probes exist.
> >
> >
"Simon Riggs" <[EMAIL PROTECTED]> 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, exc
On Tue, 2007-01-09 at 17:16 -0500, Bruce Momjian wrote:
> Tom Lane wrote:
> > > /* reset flag so that die() interrupt won't cause
> > > problems */
> > > vfdP->fdstate &= ~FD_TEMPORARY;
> > > + PG_TRACE1(temp__file__cleanup, vfdP->fileName);
> >
Tom Lane wrote:
> Bill Moran <[EMAIL PROTECTED]> writes:
> > In response to Tom Lane <[EMAIL PROTECTED]>:
> >> and then zero
> >> can be the "off" position, and we need not worry about whether -1 is
> >> -1 byte or -1 kbyte.
>
> > All doing this does is make it impossible to log temp files of 1 by
Bill Moran <[EMAIL PROTECTED]> writes:
> In response to Tom Lane <[EMAIL PROTECTED]>:
>> Hmm, that could be a little bit ugly. Suggestion: redefine the value
>> such that files *greater than* the given size are logged,
> It already is that way, with 0 effectively meaning "log all".
Oh, never min
Bill Moran <[EMAIL PROTECTED]> writes:
> In response to Tom Lane <[EMAIL PROTECTED]>:
>> and then zero
>> can be the "off" position, and we need not worry about whether -1 is
>> -1 byte or -1 kbyte.
> All doing this does is make it impossible to log temp files of 1 byte.
How you figure that? It
In response to Tom Lane <[EMAIL PROTECTED]>:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Surely the measurement unit should be kbytes or disk blocks. And why
> >> aren't you using that GUC UNITS infrastructure Peter put in?
>
> > Agreed. I have applied the following pat
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Surely the measurement unit should be kbytes or disk blocks. And why
> >> aren't you using that GUC UNITS infrastructure Peter put in?
>
> > Agreed. I have applied the following patch to make it kilobytes, and
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Surely the measurement unit should be kbytes or disk blocks. And why
>> aren't you using that GUC UNITS infrastructure Peter put in?
> Agreed. I have applied the following patch to make it kilobytes, and
> documented it. I didn't pu
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > + A value of zero logs all temporary files, and positive
> > + values log only files whose size is equal or greater than
> > + the specified number of bytes.
>
> Surely the measurement unit should be kbytes or
Bruce Momjian <[EMAIL PROTECTED]> writes:
> + A value of zero logs all temporary files, and positive
> + values log only files whose size is equal or greater than
> + the specified number of bytes.
Surely the measurement unit should be kbytes or disk blocks. And why
aren't
Bill Moran wrote:
> In response to Tom Lane <[EMAIL PROTECTED]>:
>
> > Bill Moran <[EMAIL PROTECTED]> writes:
> > > Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> > >>> Might be more robust to say
> > >>> if (trace_temp_files >= 0)
> >
> > > I specified in the GUC config that minimum allowable value
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Bi
On Jan 3, 2007, at 4:20 PM, Bill Moran wrote:
* trace_temp_files is now an int: -1 disables, 0 and up equate to
"log if
the file is this size or larger"
Another thought is to allow ignoring files over a certain size. The
reason is that if you end up creating 10MB of temp files, you can
In response to Tom Lane <[EMAIL PROTECTED]>:
> Bill Moran <[EMAIL PROTECTED]> writes:
> > Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> >>> Might be more robust to say
> >>> if (trace_temp_files >= 0)
>
> > I specified in the GUC config that minimum allowable value is -1.
>
> I'd still tend to go
Bill Moran <[EMAIL PROTECTED]> writes:
> Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>>> Might be more robust to say
>>> if (trace_temp_files >= 0)
> I specified in the GUC config that minimum allowable value is -1.
I'd still tend to go with Andrew's suggestion because it makes this
particular bit
In response to "Simon Riggs" <[EMAIL PROTECTED]>:
> On Tue, 2007-01-02 at 18:20 -0500, Tom Lane wrote:
> > Bill Moran <[EMAIL PROTECTED]> writes:
> > > In response to Alvaro Herrera <[EMAIL PROTECTED]>:
> > >> Please change things to save the stat() syscall when the feature is not
> > >> in use.
>
On Tue, 2007-01-02 at 18:20 -0500, Tom Lane wrote:
> Bill Moran <[EMAIL PROTECTED]> writes:
> > In response to Alvaro Herrera <[EMAIL PROTECTED]>:
> >> Please change things to save the stat() syscall when the feature is not
> >> in use.
>
> > Do you have a suggestion on how to do that and still ha
Bill Moran <[EMAIL PROTECTED]> writes:
> In response to Alvaro Herrera <[EMAIL PROTECTED]>:
>> Please change things to save the stat() syscall when the feature is not
>> in use.
> Do you have a suggestion on how to do that and still have the PG_TRACE1()
> work? That was specifically requested by
23 matches
Mail list logo
