On Feb 11, 2008, at 10:26 AM, Heikki Linnakangas wrote:
Hans-Juergen Schoenig wrote:
Last week we have seen a problem with some horribly configured
machine.
The disk filled up (bad FSM ;) ) and once this happened the
sysadmi killed the system (-9).
After two days PostgreSQL has still not st
We included the public domain timezone library by Arthur David Olson
back in 2004 into our source tree, but we haven't kept it up to date
with the upstream changes since.
We've made a number of small changes to our version of the library,
including:
- formatting changes, mostly thanks to pgin
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> Hans-Juergen Schoenig wrote:
>> that's where it finished, nothing else was logged between the "redo
>> done" and the last log messages
> I bet you've bumped into a bug in gist redo code, the cleanup phase
> shouldn't take long.
That's what it s
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> On investigation the problem occurs because we changed vacuum.c's
>> PageGetFreeSpaceWithFillFactor() to use PageGetHeapFreeSpace()
>> instead of just computing pd_upper - pd_lower as it had done in
>> every previ
"Tom Lane" <[EMAIL PROTECTED]> writes:
> On investigation the problem occurs because we changed vacuum.c's
> PageGetFreeSpaceWithFillFactor() to use PageGetHeapFreeSpace()
> instead of just computing pd_upper - pd_lower as it had done in
> every previous release. This was *not* a good idea: VACU
On Mon, 2008-02-11 at 10:44 +0100, Hans-Juergen Schoenig wrote:
> On Feb 11, 2008, at 10:26 AM, Heikki Linnakangas wrote:
> > Wait, are you saying that the time was spent in the rm_cleanup
> > phase? That sounds unbelievable. Surely the time was spent in the
> > redo phase, no?
> redo was done f
Hans-Juergen Schoenig wrote:
this is he last info which was issued ...
nothing in between ...
during the rm_cleanup() nothing was logged into the logs. this is the
last log from today dawn:
[2008-02-11 03:45:16 CET ]LOG: lost parent for block 8558565
[2008-02-11 03:45:16 CET ]LOG: index 1663
Last week we have seen a problem with some horribly configured machine.The disk filled up (bad FSM ;) ) and once this happened the sysadmi killed the system (-9).After two days PostgreSQL has still not started up and they tried to restart it again and again making sure that the consistency check w
On Mon, 2008-02-11 at 11:50 +0100, Hans-Juergen Schoenig wrote:
> I have that feeling too - it could very well be some Gist issue in
> here but given what we have seen in the debugger this was not too
> obvious.
> At first glance it rather felt like a full check of the entire index.
Yeh, I'm happ
I'm sorry to hear about this problem.
No worries - nothing lost ...
Not sure we need a LOG message to warn people about the possible
length
of recovery time. The chances of a recovery taking that much time seem
very low for normal Postgres, even with checkpoint parameters set at
their ma
On Mon, 2008-02-11 at 09:29 +0100, Hans-Juergen Schoenig wrote:
> Last week we have seen a problem with some horribly configured
> machine.
> The disk filled up (bad FSM ;) ) and once this happened the sysadmi
> killed the system (-9).
> After two days PostgreSQL has still not started up and they t
Hans-Juergen Schoenig wrote:
Last week we have seen a problem with some horribly configured machine.
The disk filled up (bad FSM ;) ) and once this happened the sysadmi killed the
system (-9).
After two days PostgreSQL has still not started up and they tried to restart it
again and again making
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> I was not able to find anything like release notes that would list the
> differences between tzcode2003e, which I believe is the version that we
> included back then, and the latest version tzcode2007k. So I just took a
> diff between those, and
13 matches
Mail list logo
