Skip site navigation (1) Skip section navigation (2)

Re: PreallocXlogFiles

From: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PreallocXlogFiles
Date: 2004-07-21 23:35:43
Message-ID: Pine.LNX.4.58.0407220929210.6882@linuxworld.com.au (view raw or flat)
Thread:
Lists: pgsql-hackers
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).

The question is, where to call it from. Its possible that the buffer
manager may have enough information to guess how often a new checkpoint
file should be preallocated. The alternative would be to have (yet
another) backend look after this.

Or, maybe the autovacuum backend could look after this. It would have
access to stats which may be useful but it would mean that people would
have to run autovacuum if they wanted checkpoints preallocated.

Thanks,

Gavin

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2004-07-21 23:53:33
Subject: Re: PreallocXlogFiles
Previous:From: Tom LaneDate: 2004-07-21 22:43:55
Subject: Re: PITR COPY Failure (was Point in Time Recovery)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group