Sorry, patch attached this time...
On 1/12/07, Jaime Casanova <[EMAIL PROTECTED]> wrote:
On 1/11/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-01-11 at 21:05 -0500, Jaime Casanova wrote:
> > On 1/11/07, Albert Cervera Areny <[EMAIL PROTECTED]> wrote:
> > > Please, go on with that
On 1/11/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
On Thu, 2007-01-11 at 21:05 -0500, Jaime Casanova wrote:
> On 1/11/07, Albert Cervera Areny <[EMAIL PROTECTED]> wrote:
> > Please, go on with that, I hadn't seen that problem. Indeed, I read Andrew
> > answer to your question and I think it's
On Thu, 2007-01-11 at 21:05 -0500, Jaime Casanova wrote:
> On 1/11/07, Albert Cervera Areny <[EMAIL PROTECTED]> wrote:
> > Please, go on with that, I hadn't seen that problem. Indeed, I read Andrew
> > answer to your question and I think it's a nice solution.
> >
>
> yes... i'm always trying to ki
Attached is a patch that provides an implementation of width_bucket()
for the float8 data type, per earlier discussion. The implementation is
fairly ugly, but I don't see an easy way to simplify it.
When writing this, I noticed that my previous implementation of
width_bucket() probably doesn't han
On 1/11/07, Albert Cervera Areny <[EMAIL PROTECTED]> wrote:
Please, go on with that, I hadn't seen that problem. Indeed, I read Andrew
answer to your question and I think it's a nice solution.
yes... i'm always trying to kill flies with tanks... ;)
i will use Andrew's suggestion...
--
regards
Please, go on with that, I hadn't seen that problem. Indeed, I read Andrew
answer to your question and I think it's a nice solution.
A Dimecres 10 Gener 2007 05:33, Jaime Casanova va escriure:
> On 1/9/07, Albert Cervera Areny <[EMAIL PROTECTED]> wrote:
> > I don't have much time lately so if you
On Thu, 2007-01-11 at 17:06 +, Gregory Stark wrote:
> Having a CRC in WAL but not in the heap seems kind of pointless.
Yes...
> If your
> hardware is unreliable the corruption could anywhere.
Agreed.
Other DBMS have one setting for the whole server; I've never seen
separate settings for W
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
The attached patch changes vcbuild so the project and solution files are
only regenerated if they are actually changed. This helps when you're
developing in the Visual Studio GUI, because updating the files (even to
the same contents) will cause a reload and re-parse of all the projects
in the solu
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
Hiroshi Saito wrote:
> Hi Magnus-san.
>
> I am trying simple construction by operating config.pl.
> It has changed wonderfully now. however, I do not use ecpg, and see the
> simplest construction. At that time, even pthread might not be needed.
> It was simple.
Good point, but the patch doesn't w
Hi Magnus-san.
I am trying simple construction by operating config.pl.
It has changed wonderfully now. however, I do not use ecpg,
and see the simplest construction. At that time, even pthread
might not be needed. It was simple.
Please consider this.
P.S)
I can't catch up with your quick wor
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > To get the new html dependency to work properly, I removed the
> > .SECONDARY tag from the Makefile. SECONDARY prevents missing files
> > from being built.
>
> That is not what it does.
It does several things, but that is one of the things it do
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" <[EMAIL PROTECTED]> writes:
> Oh, sorry, had the wrong context in mind. I'm still not very impressed
> with the idea --- a CRC check will catch many kinds of problems, whereas
> this approach catches exactly one kind of problem.
Well in fairness I tossed in a throwaway comment at the
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> You understand wrong ... a tuple sitting on disk is normally read
>> directly from the shared buffer, and I don't think we want to pay for
>> copying it.
> "xlog records"
Oh, sorry, had the wrong context in mind
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> "Tom Lane" <[EMAIL PROTECTED]> writes:
>>> Pretty much not happening; or are you volunteering to fix every part of
>>> the system to tolerate injections of inserted data anywhere in a stored
>>> datum?
>
>> I was
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Pretty much not happening; or are you volunteering to fix every part of
>> the system to tolerate injections of inserted data anywhere in a stored
>> datum?
> I was thinking to do it at a low level as the xlog re
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> What did you think about protecting against torn writes using id numbers
>> every
>> 512 bytes.
>
> Pretty much not happening; or are you volunteering to fix every part of
> the system to tolerate injections of
Gregory Stark <[EMAIL PROTECTED]> writes:
> What did you think about protecting against torn writes using id numbers every
> 512 bytes.
Pretty much not happening; or are you volunteering to fix every part of
the system to tolerate injections of inserted data anywhere in a stored
datum?
"Tom Lane" <[EMAIL PROTECTED]> writes:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>> COPY XLogInsert() #1 on oprofile results at 17% CPU
>> (full_page_writes = on)
>
> But what portion of that is actually CRC-related? XLogInsert does quite
> a lot.
>
> Anyway, I can't see de
On Thu, 2007-01-11 at 09:01 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > COPYXLogInsert() #1 on oprofile results at 17% CPU
> > (full_page_writes = on)
>
> But what portion of that is actually CRC-related? XLogInsert does quite
> a lot.
>
> A
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> COPY XLogInsert() #1 on oprofile results at 17% CPU
> (full_page_writes = on)
But what portion of that is actually CRC-related? XLogInsert does quite
a lot.
Anyway, I can't see degrading the reliability of the system for a gain
i
On Wed, 2007-01-10 at 23:32 -0500, Bruce Momjian wrote:
> Simon Riggs wrote:
> > On Fri, 2007-01-05 at 22:57 -0500, Tom Lane wrote:
> > > Jim Nasby <[EMAIL PROTECTED]> writes:
> > > > On Jan 5, 2007, at 6:30 AM, Zeugswetter Andreas ADI SD wrote:
> > > >> Ok, so when you need CRC's on a replicate (b
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Has anyone bothered to measure the overhead added by having to mask to
fetch or store the natts value? This is not a zero-cost improvement.
Tom, how should this be tested? I assume some loop of the same query
over an
Bruce Momjian wrote:
> To get the new html dependency to work properly, I removed the
> .SECONDARY tag from the Makefile. SECONDARY prevents missing files
> from being built.
That is not what it does.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end o
29 matches
Mail list logo
