"Greg Cox" <ratness@hotmail.com> writes:
> In the 3 days since it died, I've been watching it and, once again, the
> processes are climbing slowly again. They're idle postgres processes,
> fairly evenly distributed against the app servers, and more interestingly,
This isn't a postgres bug, it's a problem in your application code; it's
not closing sessions it doesn't need. Possibly a problem in a
connection-pooling layer?
> I looked in the 7.4 docs about WAL. checkpoint_timeout is 300,
> checkpoint_segments is 8, plenty of space in pg_xlog, but there's 18 files
> in there, some a few hours old, which I would suspect would not be the case
> if it were checkpointing properly.
No, that doesn't sound out of line. The steady state is to have about
2 * checkpoint_segments + 1 WAL files. You might have one or so more
than I'd have expected but that's not enough to evidence a problem.
If you are concerned about whether checkpoints are really happening,
use pg_controldata to keep an eye on the last-checkpoint time in
pg_control.
I concur with the other comment that you really ought to be on 7.4.latest
but that's not going to magically fix your connection-pooling issue.
regards, tom lane
