Re: Torn page hazard in ginRedoUpdateMetapage()

On Mon, Apr 30, 2012 at 02:35:20PM -0400, Tom Lane wrote:
> Noah Misch <noah(at)leadboat(dot)com> writes:
> > When GIN changes a metapage, we WAL-log its ex-header content and never use a
> > backup block. This reduces WAL volume since the vast majority of the metapage
> > is unused. However, ginRedoUpdateMetapage() only restores the WAL-logged
> > content if the metapage LSN predates the WAL record LSN. If a metapage write
> > tore and updated the LSN but not the other content, we would fail to complete
> > the update. Instead, unconditionally reinitialize the metapage similar to how
> > _bt_restore_meta() handles the situation.
>
> > I found this problem by code reading and did not attempt to build a test case
> > illustrating its practical consequences. It's possible that there's no
> > problem in practice on account of some reason I haven't contemplated.
>
> I think there's no problem in practice; the reason is that the
> GinMetaPageData struct isn't large enough to extend past the first
> physical sector of the page. So it's in the same disk sector as the
> LSN and tearing is impossible. Still, this might be a good
> future-proofing move, in case GinMetaPageData gets larger.

Can we indeed assume that all support-worthy filesystems align the start of
every file to a physical sector? I know little about modern filesystem
design, but these references leave me wary of that assumption:

http://www.mail-archive.com/linux-btrfs(at)vger(dot)kernel(dot)org/msg14690.html
http://en.wikipedia.org/wiki/Block_suballocation

If it is a safe assumption, we could exploit it elsewhere.

Thanks,
nm