Re: PreallocXlogFiles
От | Simon Riggs |
---|---|
Тема | Re: PreallocXlogFiles |
Дата | |
Msg-id | 1090663133.3057.97.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: PreallocXlogFiles (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: PreallocXlogFiles
|
Список | pgsql-hackers |
On Thu, 2004-07-22 at 15:19, Tom Lane wrote: > Simon Riggs <simon@2ndquadrant.com> writes: > > On Thu, 2004-07-22 at 01:44, Tom Lane wrote: > >> Agreed. Maybe it should be part of the bgwriter's idle loop, and > >> not directly associated with checkpoints at all. > > > Yes, thats a more natural home, now bgwriter exists. But does it know > > when log files are full? How would it know? > > It can run PreallocXlogFiles --- or more likely a modified version of > same. There isn't anything that function needs to do that the bgwriter > can't do (in fact, the bgwriter is what runs checkpoints now...) > I can see roughly how to do this, but it is a can of worms I don't want to open when I dont have much time. Some thoughts and ideas for later: The Checkpoint code writes to xlog, so finds out what the recptr is for free, then tries to act on that knowledge in PreallocXlogFiles. Calling PreallocXlogFiles outside of the Checkpoint code is straightforward to initiate from bgwriter.c, but the caller must have already obtained the current recptr position. That would require attempting to gain a lock on XLogCtl, then releasing it quickly after having read the pointer. Then call Prealloc... ...Unless there is a heuristic to use, rather than exact knowledge of the recptr...perhaps predicting something from the last 3 checkpoint durations perhaps? I'll return to this later. Best Regards, Simon Riggs
В списке pgsql-hackers по дате отправления: