On Mon, Apr 30, 2012 at 02:35:20PM -0400, Tom Lane wrote: > Noah Misch <n...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
