Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 47fe4d2

Browse files
committed
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
1 parent f78329d commit 47fe4d2

File tree

1 file changed

+1
-0
lines changed

1 file changed

+1
-0
lines changed

src/backend/access/gin/ginxlog.c

+1
Original file line numberDiff line numberDiff line change
@@ -512,6 +512,7 @@ ginRedoUpdateMetapage(XLogReaderState *record)
512512
Assert(BufferGetBlockNumber(metabuffer) == GIN_METAPAGE_BLKNO);
513513
metapage = BufferGetPage(metabuffer);
514514

515+
GinInitPage(metapage, GIN_META, BufferGetPageSize(metabuffer));
515516
memcpy(GinPageGetMeta(metapage), &data->metadata, sizeof(GinMetaPageData));
516517
PageSetLSN(metapage, lsn);
517518
MarkBufferDirty(metabuffer);

0 commit comments

Comments
 (0)