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

Re: memory-related bugs

From: Daniel Farina <daniel(at)heroku(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: memory-related bugs
Date: 2011-09-09 20:38:47
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, Sep 8, 2011 at 1:56 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

What do you mean?  As per my original bug report, or in this case
(possibly both; I should have dumped the registers, which I'll do if I
see it again...)?  I'm able to believe that things are fine with all
known memcpys today in this case.

> 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.

This is a good point, I do understand there is a distinction between
the degenerate-case memcpy-to-identical region and the

In my naivety, I'd ask what the costs are of pedantic adherence to
this common guideline and, in event someone somewhere does something
that is not expected (or, has a slow-but-not-technically-buggy memcpy)
are broken, how likely the failure will be easy to pick out.  But I
don't seriously expect an answer, because I don't think this code path
has been a problem for so many years and measuring those things are
pretty hard.


In response to

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2011-09-09 21:31:30
Subject: Re: augmenting MultiXacts to improve foreign keys
Previous:From: Martijn van OosterhoutDate: 2011-09-09 19:11:41
Subject: Re: postgresql.conf archive_command example

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