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

From: Andres Freund <andres(at)anarazel(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Subject: Re: Why are we PageInit'ing buffers in RelationAddExtraBlocks()?
Date: 2018-12-19 22:37:36
Message-ID: 20181219223736.4k2lhqoj34aaxj3m@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2018-12-19 22:41:10 Re: gist microvacuum doesn't appear to care about hot standby?
Previous Message Robert Haas 2018-12-19 22:28:17 Re: Why are we PageInit'ing buffers in RelationAddExtraBlocks()?