]> granicus.if.org Git - postgresql/commit
Move page initialization from RelationAddExtraBlocks() to use.
authorAndres Freund <andres@anarazel.de>
Mon, 28 Jan 2019 21:15:11 +0000 (13:15 -0800)
committerAndres Freund <andres@anarazel.de>
Mon, 28 Jan 2019 21:15:11 +0000 (13:15 -0800)
commite6799d5a53011985d916fdb48fe014a4ae70422e
tree15842e849cb8c648f1a9ad81597938b7181b2012
parentd4316b87bb8ec7a0ea04fb5fbc18f34a6799fe3f
Move page initialization from RelationAddExtraBlocks() to use.

Previously we initialized pages when bulk extending in
RelationAddExtraBlocks(). That has a major disadvantage: It ties
RelationAddExtraBlocks() to heap, as other types of storage are likely
to need different amounts of special space, have different amount of
free space (previously determined by PageGetHeapFreeSpace()).

That we're relying on initializing pages, but not WAL logging the
initialization, also means the risk for getting
"WARNING:  relation \"%s\" page %u is uninitialized --- fixing"
style warnings in vacuums after crashes/immediate shutdowns, is
considerably higher. The warning sounds much more serious than what
they are.

Fix those two issues together by not initializing pages in
RelationAddExtraPages() (but continue to do so in
RelationGetBufferForTuple(), which is linked much more closely to
heap), and accepting uninitialized pages as normal in
vacuumlazy.c. When vacuumlazy encounters an empty page it now adds it
to the FSM, but does nothing else.  We chose to not issue a debug
message, much less a warning in that case - it seems rarely useful,
and quite likely to scare people unnecessarily.

For now empty pages aren't added to the VM, because standbys would not
re-discover such pages after a promotion. In contrast to other sources
for empty pages, there's no corresponding WAL records triggering FSM
updates during replay.

Author: Andres Freund
Reviewed-By: Tom Lane
Discussion: https://postgr.es/m/20181219083945.6khtgm36mivonhva@alap3.anarazel.de
src/backend/access/heap/hio.c
src/backend/access/heap/vacuumlazy.c