Re: WIP: Access method extendability - Mailing list pgsql-hackers

From Aleksander Alekseev
Subject Re: WIP: Access method extendability
Date
Msg-id 20160330175920.76ea566d@fujitsu
Whole thread Raw
In response to Re: WIP: Access method extendability  (Teodor Sigaev <teodor@sigaev.ru>)
Responses Re: WIP: Access method extendability  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
List pgsql-hackers
> > http://www.postgresql.org/message-id/56EFF347.20500@anastigmatix.net
> That discussion is about SQL-level types which could be stored on
> disk, not about in-memory structs

I must respectfully disagree. That discussion is also about memory
sanitizers and using them on buildfarms. Lets say you initialize a
structure like this:

st->f1 = 111;
st->f2 = 222;

... without using memset, so there could be a "hole" with uninitialized
data somewhere in between of f1 and f2.

Than some code calculates a hash of this structure or does memcpy - and
1) You get unreproducible behavior - hash is always different for the
same structure, thus it is stored in different hash buckets, etc, and as
a result you got bugs that sometimes reproduce and sometimes do not
2) There is one more place where sanitizers could report accesses to
uninitialized values and thus they still can't be used on buildfarms
where they could find a lot of serious bugs automatically. I believe
MemorySanitizer is smart enough to recognize trivial memcpy case, but
it could be confused in more complicated cases.

Anyway I suggest continue discussion of whether we should make
PostgreSQL sanitizers-friendly or not in a corresponding thread. So far
no one spoke against this idea. Thus I don't think that new patches
should complicate implementing it. Especially considering that it's
very simple to do and even is considered a good practice according to
PostgreSQL documentation.

-- 
Best regards,
Aleksander Alekseev
http://eax.me/



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Support for N synchronous standby servers - take 2
Next
From: Andrew Dunstan
Date:
Subject: Re: [postgresSQL] [bug] Two or more different types of constraints with same name creates ambiguity while drooping.