Robert Haas <robertmh...@gmail.com> writes: > On Sun, Jul 15, 2012 at 5:36 PM, Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers