]> granicus.if.org Git - postgresql/commit
Fix WAL-logging of FSM and VM truncation.
authorHeikki Linnakangas <heikki.linnakangas@iki.fi>
Wed, 19 Oct 2016 11:26:05 +0000 (14:26 +0300)
committerHeikki Linnakangas <heikki.linnakangas@iki.fi>
Wed, 19 Oct 2016 11:26:05 +0000 (14:26 +0300)
commit917dc7d2393ce680dea7a59418be9ff341df3c14
tree3b30c4691599adba8a888781b3ac8fb2a0c83e12
parentb801e120080de836b834c1b756c4c4d81ce841b5
Fix WAL-logging of FSM and VM truncation.

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: <CABOikdNr5vKucqyZH9s1Mh0XebLs_jRhKv6eJfNnD2wxTn=_9A@mail.gmail.com>
src/backend/access/heap/visibilitymap.c
src/backend/storage/freespace/freespace.c
src/test/recovery/t/008_fsm_truncation.pl [new file with mode: 0644]