aboutsummaryrefslogtreecommitdiff
path: root/contrib/postgres_fdw/postgres_fdw.c
diff options
context:
space:
mode:
authorHeikki Linnakangas <heikki.linnakangas@iki.fi>2015-06-30 00:06:00 +0300
committerHeikki Linnakangas <heikki.linnakangas@iki.fi>2015-06-30 00:06:00 +0300
commit47fe4d25d57c81b9d7b2ac88783a12ee487db220 (patch)
tree70a1f3a1fa5f9e77b9563a0a75efcac8c23ce08a /contrib/postgres_fdw/postgres_fdw.c
parentf78329d594c2fe893f9174d5b3da7d3fbc6dd8b6 (diff)
downloadpostgresql-47fe4d25d57c81b9d7b2ac88783a12ee487db220.tar.gz
postgresql-47fe4d25d57c81b9d7b2ac88783a12ee487db220.zip
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
Diffstat (limited to 'contrib/postgres_fdw/postgres_fdw.c')
0 files changed, 0 insertions, 0 deletions