From: | Markus Schaber <schabi(at)logix-tt(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Faster StrNCpy |
Date: | 2006-09-29 09:21:21 |
Message-ID: | 451CE591.9030108@logix-tt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Hi, Tom,
Tom Lane wrote:
> "Strong, David" <david(dot)strong(at)unisys(dot)com> writes:
>> Just wondering - are any of these cases where a memcpy() would work
>> just as well? Or are you not sure that the source string is at least
>> 64 bytes in length?
>
> In most cases, we're pretty sure that it's *not* --- it'll just be a
> palloc'd C string.
>
> I'm disinclined to fool with the restriction that namestrcpy zero-pad
> Name values, because they might end up on disk, and allowing random
> memory contents to get written out is ungood from a security point of
> view.
There's another disadvantage of always copying 64 bytes:
It may be that the 64-byte range crosses a page boundary. Now guess what
happens when this next page is not mapped -> segfault.
Markus
--
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf. | Software Development GIS
Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2006-09-29 09:51:32 | Re: Block B-Tree concept |
Previous Message | Heikki Linnakangas | 2006-09-29 08:35:31 | Re: Another idea for dealing with cmin/cmax |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-09-29 14:59:22 | Re: Faster StrNCpy |
Previous Message | Florian G. Pflug | 2006-09-29 02:21:20 | Re: Patch: Tie stats options to autovacuum in postgresql.conf |