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

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Why are we PageInit'ing buffers in RelationAddExtraBlocks()?
Дата
Msg-id 20181220005636.cowkudhiu666mhdi@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Why are we PageInit'ing buffers in RelationAddExtraBlocks()?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Why are we PageInit'ing buffers in RelationAddExtraBlocks()?  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Hi,

On 2018-12-19 19:39:33 -0500, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Wed, Dec 19, 2018 at 5:37 PM Andres Freund <andres@anarazel.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Gierth
Дата:
Сообщение: Re: reducing the footprint of ScanKeyword (was Re: Large writable variables)
Следующее
От: Andres Freund
Дата:
Сообщение: Re: reducing the footprint of ScanKeyword (was Re: Large writablevariables)