Re: PreallocXlogFiles

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: PreallocXlogFiles
Date: 2004-07-22 00:41:01
Message-ID: 1090456861.2658.1440.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 2004-07-22 at 00:35, Gavin Sherry wrote:
> On Wed, 21 Jul 2004, Simon Riggs wrote:
>
> > I notice this:
> >
> > When a checkpoint occurs, if a log file is more than 75% full then a new
> > file will be allocated (in PreallocXlogFiles).
> >
> > This assumes we checkpoint at least 4 times per log file, otherwise it
> > will be effectively random whether we actually ever do this or not. With
> > an uneven or bursty workload, we would need to checkpoint many more
> > times per xlog to even notice this is ever being called. (I never have).
> >
> > ...but we don't check that anywhere in the code.
>
> I prefer the idea of just checking it more often than pulling the code out
> all together. I think this sits well with Jan's work on consistent
> availability (buffer manager, vacuum delay).
>

Good idea. Hey - we could get archiver to do this, seeing as it knows
when the logs are full. Just do: I've seen a full one, I'll prealloc
another. No test, just alloc. (Or the bgwriter...)

On Thu, 2004-07-22 at 00:53, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > I would like to remove PreallocXlogFiles on the basis that it is dead,
> > or at least pointless code.
>
> I wonder whether we should not put back the preallocated-files GUC
> parameter that Bruce took out a release or two back. PreallocXlogFiles
> made a lot more sense back when that parameter existed.

That's simplest, especially if the code is there.

But again, if you set it to a constant value it's not really responding
to system demands, its just the admin's guess of what to set it to.

Gavin's idea sounds more optimal...

However, I'm not at all convinced that this analysis holds up with
> bursty traffic or when the archiver is delaying rotation of old xlogs.
> If the number of physical WAL files needs to grow and shrink because
> of such effects, then PreallocXlogFiles is the only thing that can
> prevent foreground processes from having to do the work that should
> be handled by the checkpointer.

Yes, I agree, but the checkpointer isn't waking up often enough
currently to do this effectively. It's just randomly doing it.

Best regards, Simon Riggs

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-07-22 00:43:07 Re: PITR COPY Failure (was Point in Time Recovery)
Previous Message Tom Lane 2004-07-22 00:40:19 Re: Why we really need timelines *now* in PITR