On 2016-08-18 20:02, Heikki Linnakangas wrote:
> On 03/22/2016 03:27 PM, Aleksander Alekseev wrote:
>> diff --git a/src/backend/utils/mmgr/aset.c
>> b/src/backend/utils/mmgr/aset.c
>> index d26991e..46ab8a2 100644
>> --- a/src/backend/utils/mmgr/aset.c
>> +++ b/src/backend/utils/mmgr/aset.c
>> @@ -850,7 +850,7 @@ AllocSetAlloc(MemoryContext context, Size size)
>>              blksize <<= 1;
>>          /* Try to allocate it */
>> -        block = (AllocBlock) malloc(blksize);
>> +        block = (AllocBlock) calloc(1, blksize);
>>          /*
>>           * We could be asking for pretty big blocks here, so cope if
>> malloc

> I think this goes too far. You're zeroing all palloc'd memory, even if
> it's going to be passed to palloc0(), and zeroed there. It might even
> silence legitimate warnings, if there's code somewhere that does
> palloc(), and accesses some of it before initializing. Plus it's a
> performance hit.

I just did a test where I
1. memset() that block to 0xAC (aset.c:853)
2. compile and run bin/initdb, then bin/postgres
2. run an SQL file, shut down bin/postgres
3. make a copy of the transaction log file
4. change the memset() to 0x0C, repeat steps 2-3
5. compare the two transaction log files with a combination of 
hexdump(1), cut(1), and diff(1).

At the end of the output I can see:

-0f34 0010 0000 f5ff ac02 000a 0000 0000
+0f34 0010 0000 f5ff 0c02 000a 0000 0000

So it looks like the MSan complaint might be a true positive.

The SQL file is just this snippet from bit.sql:
CREATE TABLE varbit_table (a BIT VARYING(16), b BIT VARYING(16));
COPY varbit_table FROM stdin;
X0F     X10
X1F     X11
X2F     X12
X3F     X13
X8F     X04
X000F   X0010
X0123   XFFFF
X2468   X2468
XFA50   X05AF
X1234   XFFF5

I realize given information might be a little bit scarce, but I didn't 
know what else might be interesting to you that you wouldn't be able to 

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to