Fix WAL-logging of FSM and VM truncation

Enterprise / PostgreSQL - Heikki Linnakangas [iki.fi] - 19 October 2016 06:26 UTC

When a relation is truncated, it is important that the FSM is truncated as well. Otherwise, after recovery, the FSM can return a page that has been truncated away, leading to errors like:

ERROR: could not read block 28991 in file "base/16390/572026": read only 0 of 8192 bytes

We were using MarkBufferDirtyHint() to dirty the buffer holding the last remaining page of the FSM, but during recovery, that might in fact not dirty the page, and the FSM update might be lost.

To fix, use the stronger MarkBufferDirty() function. MarkBufferDirty() requires us to do WAL-logging ourselves, to protect from a torn page, if checksumming is enabled.

Also fix an oversight in visibilitymap_truncate: it also needs to WAL-log when checksumming is enabled.

Analysis by Pavan Deolasee.

Discussion:

917dc7d Fix WAL-logging of FSM and VM truncation.
src/backend/access/heap/visibilitymap.c | 16 +++++
src/backend/storage/freespace/freespace.c | 20 ++++++-
src/test/recovery/t/008_fsm_truncation.pl | 93 +++++++++++++++++++++++++++++
3 files changed, 128 insertions(+), 1 deletion(-)

Upstream: git.postgresql.org

  • Share