Re: CompactCheckpointerRequestQueue versus pad bytes

From: pgsql-hackers-owner(at)postgresql(dot)org
[mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Tom Lane
Sent: Monday, July 16, 2012 3:06 AM

> It might have accidentally failed to fail if tested on a compiler that
> gives a full 32 bits to enum ForkNumber, but there absolutely would be
> padding there if ForkNumber is allocated as short or char.

> As best I can tell, a failure from uninitialized padding would not cause
> visible misbehavior but only make it not notice that two requests are
> identical, so that the queue compaction would not accomplish as much as
> it should. Nonetheless, this seems pretty broken.

> 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?

If we just document those structs, then how to handle the case where
ForkNumber
is allocated as short or char?