[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: [HACKERS] Torn page hazard in ginRedoUpdateMetapage()
From:       Tom Lane <tgl () sss ! pgh ! pa ! us>
Date:       2012-04-30 18:35:20
Message-ID: 21243.1335810920 () sss ! pgh ! pa ! us
[Download RAW message or body]

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.

			regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[prev in list] [next in list] [prev in thread] [next in thread]