Re: Torn page hazard in ginRedoUpdateMetapage() - Mailing list pgsql-hackers

From Noah Misch
Subject Re: Torn page hazard in ginRedoUpdateMetapage()
Date
Msg-id 20120503010648.GA5386@tornado.leadboat.com
Whole thread Raw
In response to Re: Torn page hazard in ginRedoUpdateMetapage()  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Torn page hazard in ginRedoUpdateMetapage()
List pgsql-hackers
On Mon, Apr 30, 2012 at 02:35:20PM -0400, Tom Lane wrote:
> Noah Misch <noah@leadboat.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@vger.kernel.org/msg14690.html
http://en.wikipedia.org/wiki/Block_suballocation

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

Thanks,
nm


pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap
Next
From: Tom Lane
Date:
Subject: Re: Latch for the WAL writer - further reducing idle wake-ups.