Skip site navigation (1) Skip section navigation (2)

Re: memory-related bugs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniel Farina <daniel(at)heroku(dot)com>
Cc: Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: memory-related bugs
Date: 2011-09-08 20:56:09
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Daniel Farina <daniel(at)heroku(dot)com> writes:
> On Tue, Sep 6, 2011 at 12:00 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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
> cause an infinite loop on ssse3 architectures, having to do with some
> backwards-iteration it does:

The linked page offers no support for your claim of an infinite loop,
and in any case it's discussing a case involving *overlapping* regions,
not *identical* regions.

The reason why this concern is irrelevant for identical regions is that
no matter what order the memcpy routine copies the bytes in, it's
necessarily storing the exact same data into each byte that was there
before.  The only way that strange results could be produced is if the
routine transiently set some byte to a value other than its final value,
which would mean that it must be intending to store to that location
more than once, which would be silly and inefficient.

So I'm not going to believe that there's a problem here without a lot
more rigorous evidence than anyone has offered.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Magnus HaganderDate: 2011-09-08 21:03:06
Subject: Re: Protecting against multiple instances per cluster
Previous:From: Peter GeogheganDate: 2011-09-08 20:45:56
Subject: Re: Large C files

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group