Re: CompactCheckpointerRequestQueue versus pad bytes

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Jul 16, 2012 at 11:57 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> BTW, I'd be a lot happier about assuming that bare RelFileNode contains
>> no padding, because that's at least got all the fields the same type.
>> So that brings us back to the question of why this code is supporting
>> fsync requests for local relations in the first place. Couldn't we have
>> it ignore those, and then only ship RelFileNode to the checkpointer?

> That's an awfully good point. I think that was just sloppy coding on
> my part (cf commit debcec7dc31a992703911a9953e299c8d730c778). +1 for
> changing it as you suggest.

OK, so I think the current proposal is:

1. Document that RelFileNode must not contain padding.

2. Change the fsync forwarding code to ignore backend-local relations,
and include only RelFileNode not RelFileNodeBackend in requests.

3. Zero the checkpointer requests[] array at shmem init time, so as
to ensure consistency of any pad bytes elsewhere in the request structs.

I will see about making this happen. Since the fsync queue compaction
code got back-patched awhile ago, we need to back-patch the relevant
parts of this too.

regards, tom lane