In response to "Guillaume Smet" <[EMAIL PROTECTED]>:
> On 1/12/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > Usually people don't want th query unless they ask for it. One nify
> > trick would be to print the query as DETAIL unless they are already
> > logging queries, but that just seems too
On 1/12/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Usually people don't want th query unless they ask for it. One nify
trick would be to print the query as DETAIL unless they are already
logging queries, but that just seems too complex. If you want the
query, why not just log them all?
Beca
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> On 1/12/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> (2) there is already a generalized solution to this, it's called
>> log_min_error_statement.
> I didn't think of that when posting my message but Bruce seems to say
> that we can't use it in this case
On 1/12/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> That's not what I had in mind. I was asking if the text of the query
> was available when logging the temp file usage. If so it could be good
> to add a DETAIL line with it directly and systematically w
"Guillaume Smet" <[EMAIL PROTECTED]> writes:
> That's not what I had in mind. I was asking if the text of the query
> was available when logging the temp file usage. If so it could be good
> to add a DETAIL line with it directly and systematically when logging
> the temp file usage.
(1) you could
Hi Bruce,
Thanks for your answer.
On 1/12/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
We have the ability to conditionally print statements based on error
level, but LOG isn't a valid level for log_min_error_statement.
We could add a parameter that few people would use, but the right way to
d
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
In response to Bruce Momjian <[EMAIL PROTECTED]>:
>
> I have applied a modified version of your patch. I renamed the
> parameter to 'log_temp_files', for consistency, added documentation, and
> improved the wording, particularly mentioning that the logging happens
> at file deletion time.
Thanks
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
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
Bill Moran wrote:
In response to "Andrew Dunstan" <[EMAIL PROTECTED]>:
Bill Moran wrote:
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
Bill Moran wrote:
+ if (trace_temp_files != -1)
Might be more robust to say
if (trace_temp_files >= 0)
In response to "Andrew Dunstan" <[EMAIL PROTECTED]>:
> Bill Moran wrote:
> > Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> >>
> >> Bill Moran wrote:
> >> > +if (trace_temp_files != -1)
> >> >
> >>
> >> Might be more robust to say
> >>
> >> if (trace_temp_files >= 0)
> >
> > Becau
Bill Moran wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>>
>> Bill Moran wrote:
>> > + if (trace_temp_files != -1)
>> >
>>
>> Might be more robust to say
>>
>> if (trace_temp_files >= 0)
>
> Because it would allow for the easy addition of more negative numbers
> with magic value?
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
> Bill Moran wrote:
> > + if (trace_temp_files != -1)
> >
>
> Might be more robust to say
>
> if (trace_temp_files >= 0)
Because it would allow for the easy addition of more negative numbers
with magic value?
-
Bill Moran wrote:
+ if (trace_temp_files != -1)
Might be more robust to say
if (trace_temp_files >= 0)
cheers
andrew
---(end of broadcast)---
TIP 6: explain analyze is your friend
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
In response to Alvaro Herrera <[EMAIL PROTECTED]>:
> Bill Moran wrote:
> >
> > Thanks to Simon Riggs and Bruce for input that helped me put this together.
>
> 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 h
Bill Moran wrote:
+ if (stat(vfdP->fileName, &filestats) == 0) {
+ if (trace_temp_files)
Shouldn't these tests be the other way around?
cheers
andrew
---(end of broadcast)---
TIP 7: You can help support the Postgre
Bill Moran wrote:
>
> Thanks to Simon Riggs and Bruce for input that helped me put this together.
Please change things to save the stat() syscall when the feature is not
in use.
Nitpick: also note our brace placement convention (though this would be
fixed by pgindent, but still).
--
Alvaro Her
Thanks to Simon Riggs and Bruce for input that helped me put this together.
--
Bill Moran
Collaborative Fusion Inc.
diff -c -r src.orig/backend/storage/file/fd.c src/backend/storage/file/fd.c
*** src.orig/backend/storage/file/fd.c Thu Dec 7 15:44:42 2006
--- src/backend/storage/file/fd.c Tue J
38 matches
Mail list logo
