First, I better let you know that we have an in-house patch already on our
postgres, so this may be our breakage. It only started happening recently,
though, and our patch is quite old, so it is very unlikely.
I thought I'd ask here anyway, incase this was a known bug that was fixed
already. I cou
> > What I don't grok is why all the affected files were indexes, and none
> > of the heap files appeared to have junk pages
>
> Hmmm ... that is mildly interesting, but it doesn't rise to the level of
> warning bells in my head.
I played around a bit yesterday with an INSERT'ing shell script and
why all the affected files were indexes, and none
of the heap files appeared to have junk pages
Guy Thornley
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
the last blocks in each file invalid!
- postgres attempts to recover from its log, and bumps into the (now
garbage) blocks
I'll see if I can get some time to reproduce this reliably
Guy Thornley
---(end of broadcast)---
TIP 7: don't for
On Tue, Sep 02, 2003 at 12:17:28AM -0400, Tom Lane wrote:
> Guy Thornley <[EMAIL PROTECTED]> writes:
> > What sort of performance numbers are you looking for? Without the throttle,
> > I/O is nuked and other database activity takes an age, and with it, its much
> > ha
On Mon, Sep 01, 2003 at 09:05:33AM -0400, Tom Lane wrote:
> Guy Thornley <[EMAIL PROTECTED]> writes:
> > Below is a patch for the lazy vacuum. It implements a simple I/O throttle so
> > boxen arnt killed for hours a day when VACUUM runs.
>
> Wasn't this idea
Below is a patch for the lazy vacuum. It implements a simple I/O throttle so
boxen arnt killed for hours a day when VACUUM runs. Patch includes a
paragraph for the manual. The new setting is VACUUM_THROTTLE. It can be SET
from a client connection, too.
The usleep() could be replaced with a select(
