diff options
| author | Heikki Linnakangas <heikki.linnakangas@iki.fi> | 2015-07-20 16:02:28 +0300 |
|---|---|---|
| committer | Heikki Linnakangas <heikki.linnakangas@iki.fi> | 2015-07-20 22:34:01 +0300 |
| commit | eb11de8ff5eac3592d539ad7ca3059c02e4d3e99 (patch) | |
| tree | 639092b5aa7073547643264635d9800bb3ae8ad5 /src/backend/commands/functioncmds.c | |
| parent | e52b690cf55f303839f12f8f1f136d2366d36298 (diff) | |
| download | postgresql-eb11de8ff5eac3592d539ad7ca3059c02e4d3e99.tar.gz postgresql-eb11de8ff5eac3592d539ad7ca3059c02e4d3e99.zip | |
Sanity-check that a page zeroed by redo routine is marked with WILL_INIT.
There was already a sanity-check in the other direction: if a page was
marked with WILL_INIT, it had to be initialized by the redo routine. It's
not strictly necessary for correctness that a page is marked with WILL_INIT
if it's going to be initialized at redo, but it's a missed optimization if
nothing else.
Fix a few instances of this issue in SP-GiST, where a block in WAL record
was not marked with WILL_INIT, but was in fact always initialized at redo.
We were creating a full-page image of the page unnecessarily in those
cases.
Backpatch to 9.5, where the new WILL_INIT flag was added.
Diffstat (limited to 'src/backend/commands/functioncmds.c')
0 files changed, 0 insertions, 0 deletions