Re: Why are we PageInit'ing buffers in RelationAddExtraBlocks()? - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Why are we PageInit'ing buffers in RelationAddExtraBlocks()?
Date
Msg-id 20181219223736.4k2lhqoj34aaxj3m@alap3.anarazel.de
Whole thread Raw
In response to Re: Why are we PageInit'ing buffers in RelationAddExtraBlocks()?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Why are we PageInit'ing buffers in RelationAddExtraBlocks()?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Hi,

On 2018-12-19 17:28:17 -0500, Robert Haas wrote:
> On Wed, Dec 19, 2018 at 3:39 AM Andres Freund <andres@anarazel.de> wrote:
> > Thinking about whether it's worth to allow to extend that function in an
> > extensible manner made me wonder:  Is it actually a good idea to
> > initialize the page at that point, including marking it dirty?
> 
> As far as I can recall, my motivation was to avoid increasing the
> number of warnings produced by VACUUM.  If those warnings are going
> away, then I don't know that there's any reason to keep that code as
> it is.  But I am not sure whether such a move would provoke any
> opposition.

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.  If the logic
were that we'd never reuse empty pages because they can hide corruption
that normally would discovered by checksums, then we shouldn't
reinitialize them at all and instead error out hard - but we can't do
that, because it's normal that they occur.  Right now we have empty
pages on-disk whenever a busy server is restarted in immediate mode,
after all.

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Why are we PageInit'ing buffers in RelationAddExtraBlocks()?
Next
From: Alexander Korotkov
Date:
Subject: Re: gist microvacuum doesn't appear to care about hot standby?