Skip site navigation (1) Skip section navigation (2)

Re: Torn page hazard in ginRedoUpdateMetapage()

From: Noah Misch <noah(at)leadboat(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Torn page hazard in ginRedoUpdateMetapage()
Date: 2012-05-03 01:06:48
Message-ID: 20120503010648.GA5386@tornado.leadboat.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-05-03 03:42:40
Subject: Re: Latch for the WAL writer - further reducing idle wake-ups.
Previous:From: Josh BerkusDate: 2012-05-03 01:01:38
Subject: Re: patch submission: truncate trailing nulls from heap rows to reduce the size of the null bitmap

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group