From 47fe4d25d57c81b9d7b2ac88783a12ee487db220 Mon Sep 17 00:00:00 2001 From: Heikki Linnakangas Date: Tue, 30 Jun 2015 00:06:00 +0300 Subject: [PATCH] Initialize GIN metapage correctly when replaying metapage-update WAL record. I broke this with my WAL format refactoring patch. Before that, the metapage was read from disk, and modified in-place regardless of the LSN. That was always a bit silly, as there's no need to read the old page version from disk disk when we're overwriting it anyway. So that was changed in 9.5, but I failed to add a GinInitPage call to initialize the page-headers correctly. Usually you wouldn't notice, because the metapage is already in the page cache and is not zeroed. One way to reproduce this is to perform a VACUUM on an already vacuumed table (so that the vacuum has no real work to do), immediately after a checkpoint, and then perform an immediate shutdown. After recovery, the page headers of the metapage will be incorrectly all-zeroes. Reported by Jeff Janes --- src/backend/access/gin/ginxlog.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/backend/access/gin/ginxlog.c b/src/backend/access/gin/ginxlog.c index ea85c4e2c0..d9b0ce02ac 100644 --- a/src/backend/access/gin/ginxlog.c +++ b/src/backend/access/gin/ginxlog.c @@ -512,6 +512,7 @@ ginRedoUpdateMetapage(XLogReaderState *record) Assert(BufferGetBlockNumber(metabuffer) == GIN_METAPAGE_BLKNO); metapage = BufferGetPage(metabuffer); + GinInitPage(metapage, GIN_META, BufferGetPageSize(metabuffer)); memcpy(GinPageGetMeta(metapage), &data->metadata, sizeof(GinMetaPageData)); PageSetLSN(metapage, lsn); MarkBufferDirty(metabuffer); -- 2.40.0