Re: Why are we PageInit'ing buffers in RelationAddExtraBlocks()?

Hi,

On 2018-12-19 19:39:33 -0500, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Wed, Dec 19, 2018 at 5:37 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> >> What's gained by the logic of emitting that warning in VACUUM after a
> >> crash? I don't really see any robustness advantages in it.
>
> > I don't know. I am just normally reluctant to change things
> > precipitously that are of long tenure.
>
> Me too, but I think Andres has a point here. Those warnings in VACUUM
> are ancient, probably predating the introduction of WAL :-(. At the
> time there was good reason to be suspicious of zeroed pages in tables.
> Now, though, we have (what we think is) a bulletproof crash recovery
> procedure in which possibly-zeroed pages are to be expected; so we're
> just causing users unnecessary alarm by warning about them. I think
> it's reasonable to, if not remove the messages entirely, at least
> downgrade them to a low DEBUG level.

Yea, I think that'd be reasonable.

I think we ought to add them, as new/zero pages, to the FSM. If we did
so both during vacuum and RelationAddExtraBlocks() we'd avoid the
redundant writes, and avoid depending on heap layout in
RelationAddExtraBlocks().

I wonder if it'd make sense to only log a DEBUG if there's no
corresponding FSM entry. That'd obviously not be bulltproof, but it'd
reduce the spammyness considerably.

Greetings,

Andres Freund