Re: Avoiding unnecessary reads in recovery

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Avoiding unnecessary reads in recovery
Дата
Msg-id 462FCBB9.1010407@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Avoiding unnecessary reads in recovery  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Avoiding unnecessary reads in recovery  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane wrote:
> "Simon Riggs" <simon@2ndquadrant.com> writes:
>> As regards the zero_damaged_pages question, I raised that some time ago
>> but we didn't arrive at an explicit answer. All I would say is we can't
>> allow invalid pages in the buffer manager at any time, whatever options
>> we have requested, otherwise other code will fail almost immediately.
> 
> Yeah --- the proposed new bufmgr routine should probably explicitly zero
> the content of the buffer.  It doesn't really matter in the context of
> WAL recovery, since there can't be any concurrent access to the buffer,
> but it'd make it safe to use in non-WAL contexts (I think there are
> other places where we know we are going to init the page and so a
> physical read is a waste of time).

Is there? I can't think of any. Extending a relation doesn't count.

Zeroing the buffer explicitly might be a good idea anyway. I agree it 
feels a bit dangerous to have a moment when there's a garbled page in 
buffer cache, even if only in recovery.

> Also, this would let the patch be
> 
> +    if (alloc_only)
> +        MemSet...
> +    else
>         smgrread...
> 
> and you don't need to hack out the PageHeaderIsValid test, since it will
> allow zeroed pages.

Well, I'd still put the PageHeaderIsValid test in the else-branch. Not 
like the few cycles spent on the test matter, but I don't see a reason 
not to.

> Possibly ReadZeroedBuffer would be a better name?

Yeah, sounds good. "Read" is a bit misleading, since it doesn't actually 
read in the buffer, but it's good that the name is closely related to 
ReadBuffer.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


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

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: [BUGS] BUG #3245: PANIC: failed to re-find shared loc k o b j ect
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [BUGS] BUG #3245: PANIC: failed to re-find shared loc k o b j ect