CompactCheckpointerRequestQueue supposes that it can use an entry of the checkpointer request queue directly as a hash table key. This will work reliably only if there are no pad bytes in the CheckpointerRequest struct, which means in turn that neither RelFileNodeBackend nor RelFileNode can contain any pad bytes.
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? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers