On 2013-02-17 19:52:16 +, Peter Geoghegan wrote:
> On 17 February 2013 19:39, anara...@anarazel.de wrote:
> > What patch are you talking about? I have no knowledge about any pending
> > valgrind patches except one I made upstream apply to make pg inside
> > valgrind work on amd64.
>
> Noah
Peter Geoghegan schrieb:
>On 17 February 2013 18:52, anara...@anarazel.de
>wrote:
>> You already need a suppression file to use valgrind sensibly, its
>easy enough to add it there. Perhaps we should add one to the tree?
>
>Perhaps you should take the time to submit a proper Valgrind patch
>fir
On 17 February 2013 18:52, anara...@anarazel.de wrote:
> You already need a suppression file to use valgrind sensibly, its easy enough
> to add it there. Perhaps we should add one to the tree?
Perhaps you should take the time to submit a proper Valgrind patch
first. The current approach of apply
Tom Lane schrieb:
>Boszormenyi Zoltan writes:
>> Then, why isn't memcpy() skipped if the source and dest are the same?
>> It would be a micro-optimization but a valid one.
>
>No, it'd be more like a micro-pessimization, because the test would be
>wasted effort in the vast majority of calls. T
Tom Lane schrieb:
>Andres Freund writes:
>> On 2013-02-17 15:10:35 +, Greg Stark wrote:
>>> Peter G is sitting near me and reminded me that this issue came up
>in the
>>> past. Iirc the conclusion then is that we're calling memcpy where
>the
>>> source and destination pointers are sometime
On Sun, Feb 17, 2013 at 4:26 PM, Tom Lane wrote:
> No, it'd be more like a micro-pessimization, because the test would be
> wasted effort in the vast majority of calls. The *only* reason to do
> this would be to shut up valgrind, and that seems annoying.
In terms of runtime I strongly suspect th
Boszormenyi Zoltan writes:
> Then, why isn't memcpy() skipped if the source and dest are the same?
> It would be a micro-optimization but a valid one.
No, it'd be more like a micro-pessimization, because the test would be
wasted effort in the vast majority of calls. The *only* reason to do
this
2013-02-17 16:32 keltezéssel, Tom Lane írta:
Andres Freund writes:
On 2013-02-17 15:10:35 +, Greg Stark wrote:
Peter G is sitting near me and reminded me that this issue came up in the
past. Iirc the conclusion then is that we're calling memcpy where the
source and destination pointers are
Andres Freund writes:
> On 2013-02-17 15:10:35 +, Greg Stark wrote:
>> Peter G is sitting near me and reminded me that this issue came up in the
>> past. Iirc the conclusion then is that we're calling memcpy where the
>> source and destination pointers are sometimes identical. Tom decided ther
On 2013-02-17 15:10:35 +, Greg Stark wrote:
> Peter G is sitting near me and reminded me that this issue came up in the
> past. Iirc the conclusion then is that we're calling memcpy where the
> source and destination pointers are sometimes identical. Tom decided there
> was really no realistic
Peter G is sitting near me and reminded me that this issue came up in the
past. Iirc the conclusion then is that we're calling memcpy where the
source and destination pointers are sometimes identical. Tom decided there
was really no realistic architecture where that wouldn't work. We're not
calling
11 matches
Mail list logo