Re: CompactCheckpointerRequestQueue versus pad bytes

On Mon, Jul 16, 2012 at 12:27 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> The documentation on MacOS X isn't quite as explicit, but I'd still be
>> astonished if we found any other behavior. TBH, I'd be kind of
>> surprised if this is the only place in our code base that relies on
>> the initial contents of shared memory being all-zeros.
>
> Maybe so, but if we find any others, I'll be wanting to change them too.
> It's bad practice and worse documentation for modules to be silently
> assuming that anything has a value they didn't explicitly give it.
>
> A related practice that probably costs us a lot more, in both code space
> and time, is that most (all?) places that create Node objects explicitly
> initialize every field of the Node struct, even though makeNode() has
> a palloc0 underneath it and so setting fields to zero is redundant.
> I believe that this is a good practice anyway, for documentation and
> code greppability reasons.

I don't really agree; I find it nice and clean to assume that
functions that promise to return zero'd memory really do. In my book,
the main reason for keeping things as they are is that it's probably
not costing enough to matter very much. Which is true here, too, so
I'm not going to make a huge stink, but I still think it's a waste of
effort.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company