Re: CompactCheckpointerRequestQueue versus pad bytes

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sun, Jul 15, 2012 at 5:36 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> We could fairly cheaply dodge the problem with padding after ForkNumber
>> if we were to zero out the whole request array at shmem initialization,
>> so that any such pad bytes are guaranteed zero. However, padding in
>> RelFileNodeBackend would be more annoying to deal with, and at least
>> in the current instantiation of those structs it's probably impossible
>> anyway. Should we document those structs as required to not contain
>> any padding, or do what's needful in checkpointer.c to not depend on
>> there not being padding?

> I would expect that every method we could devise for allocating a
> shared memory segment would produce all-zero bytes.

Well, it'd likely produce all-something bytes, but I don't believe
shmget is documented to produce zeroes. In any case we are not in
the habit of relying on that and I don't see why we'd do so here rather
than explicitly zeroing the relatively small amount of memory involved.

> So I'm having a hard time understanding under what imaginable set of
> circumstances this might break.

Padding inside RelFileNodeBackend would break it, because
ForwardFsyncRequest copies the rnode as a struct. So that's why I'm
asking whether we want to establish an explicit requirement that that
struct not contain any padding.

It would not be that hard to avoid the problem: we could make
CompactCheckpointerRequestQueue pre-zero a tag variable and then copy
the live fields into it. Unless there is some other place in the system
that depends on RelFileNodeBackend being non-padded, and will break in a
more visible fashion with padding, I'm now inclined to do it like that.

regards, tom lane