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:
If it is a safe assumption, we could exploit it elsewhere.
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2012-05-03 03:42:40|
|Subject: Re: Latch for the WAL writer - further reducing idle wake-ups. |
|Previous:||From: Josh Berkus||Date: 2012-05-03 01:01:38|
|Subject: Re: patch submission: truncate trailing nulls from heap
rows to reduce the size of the null bitmap|