Re: PreallocXlogFiles - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: PreallocXlogFiles
Date
Msg-id 1090663133.3057.97.camel@localhost.localdomain
Whole thread Raw
In response to Re: PreallocXlogFiles  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: PreallocXlogFiles
List 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 by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Fixing PKs and Uniques in tablespaces
Next
From: Tom Lane
Date:
Subject: Re: PreallocXlogFiles