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
|
Список | 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 по дате отправления: