Re: [HACKERS] overlapping strncpy/memcpy errors via valgrind

2013-02-17 Thread Andres Freund
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

Re: [HACKERS] overlapping strncpy/memcpy errors via valgrind

2013-02-17 Thread anara...@anarazel.de
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

Re: [HACKERS] overlapping strncpy/memcpy errors via valgrind

2013-02-17 Thread Peter Geoghegan
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

Re: [HACKERS] overlapping strncpy/memcpy errors via valgrind

2013-02-17 Thread anara...@anarazel.de
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

Re: [HACKERS] overlapping strncpy/memcpy errors via valgrind

2013-02-17 Thread anara...@anarazel.de
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

Re: [HACKERS] overlapping strncpy/memcpy errors via valgrind

2013-02-17 Thread Greg Stark
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

Re: [HACKERS] overlapping strncpy/memcpy errors via valgrind

2013-02-17 Thread Tom Lane
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

Re: [HACKERS] overlapping strncpy/memcpy errors via valgrind

2013-02-17 Thread Boszormenyi Zoltan
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

Re: [HACKERS] overlapping strncpy/memcpy errors via valgrind

2013-02-17 Thread Tom Lane
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

Re: [HACKERS] overlapping strncpy/memcpy errors via valgrind

2013-02-17 Thread Andres Freund
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

Re: [HACKERS] overlapping strncpy/memcpy errors via valgrind

2013-02-17 Thread Greg Stark
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