On Thu, Sep 8, 2011 at 1:56 PM, Tom Lane wrote:
> Daniel Farina writes:
>> On Tue, Sep 6, 2011 at 12:00 PM, Tom Lane wrote:
>>> I'm still of the opinion that there's no real need to avoid memcpy with
>>> identical source and destination, so I didn't apply this first patch.
>
>> I am leery of mem
Daniel Farina writes:
> On Tue, Sep 6, 2011 at 12:00 PM, Tom Lane wrote:
>> I'm still of the opinion that there's no real need to avoid memcpy with
>> identical source and destination, so I didn't apply this first patch.
> I am leery of memcpy with overlapping regions. I know that it can
> caus
On Tue, Sep 6, 2011 at 12:00 PM, Tom Lane wrote:
> [ Sorry for letting this slip through the cracks ... I think I got
> distracted by collation bugs :-( ]
>
> Noah Misch writes:
>> On Sat, Mar 12, 2011 at 12:44:29PM -0500, Tom Lane wrote:
>>> Noah Misch writes:
A suitably-instrumented run
On Tue, Sep 06, 2011 at 03:00:42PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Sat, Mar 12, 2011 at 12:44:29PM -0500, Tom Lane wrote:
> >> I wonder whether we should instead fix this by copying the correct tuple
> >> length.
>
> > Seems like a step in the wrong direction. We only use typl
[ Sorry for letting this slip through the cracks ... I think I got
distracted by collation bugs :-( ]
Noah Misch writes:
> On Sat, Mar 12, 2011 at 12:44:29PM -0500, Tom Lane wrote:
>> Noah Misch writes:
>>> A suitably-instrumented run of "make installcheck-world" under valgrind
>>> turned
>>>
Bruce Momjian writes:
> Did we conclude any of these were useful?
> http://archives.postgresql.org/pgsql-hackers/2011-03/msg00856.php
> I know there were concerns about some of them in the thread.
Hmm, I guess this slipped through the cracks. I thought that avoiding
memcpy(x, x, n) was unn
Noah Misch wrote:
> A suitably-instrumented run of "make installcheck-world" under valgrind turned
> up a handful of memory-related bugs:
>
> * memcpy()/strncpy() between overlapping regions
> uniqueentry() and dispell_lexize() both deduplicate an array by iteratively
> copying elements downward t
On Sat, Mar 12, 2011 at 12:44:29PM -0500, Tom Lane wrote:
> Noah Misch writes:
> > A suitably-instrumented run of "make installcheck-world" under valgrind
> > turned
> > up a handful of memory-related bugs:
>
> Hmm, interesting work, but I don't think I believe in the necessity for
> this kluge:
On Sat, Mar 12, 2011 at 04:08:23PM +, Greg Stark wrote:
> On Sat, Mar 12, 2011 at 1:32 PM, Noah Misch wrote:
> > A suitably-instrumented run of "make installcheck-world" under valgrind
> > turned
> > up a handful of memory-related bugs:
>
>
> Nice work. How did you instrument things so valg
Noah Misch writes:
> A suitably-instrumented run of "make installcheck-world" under valgrind turned
> up a handful of memory-related bugs:
Hmm, interesting work, but I don't think I believe in the necessity for
this kluge:
> + else if (attributeName != &(att->attname))
> + namest
On Sat, Mar 12, 2011 at 1:32 PM, Noah Misch wrote:
> A suitably-instrumented run of "make installcheck-world" under valgrind turned
> up a handful of memory-related bugs:
Nice work. How did you instrument things so valgrind knew about palloc
et al? I remember trying this in the past and running
A suitably-instrumented run of "make installcheck-world" under valgrind turned
up a handful of memory-related bugs:
* memcpy()/strncpy() between overlapping regions
uniqueentry() and dispell_lexize() both deduplicate an array by iteratively
copying elements downward to occlude the duplicates. Bef
12 matches
Mail list logo
