From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.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? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
