Jeff Amiel <[EMAIL PROTECTED]> writes:
> Would a good stack trace (assuming I want to crash my
> database again) help here?
Well, it'd be more information than we have now ...
regards, tom lane
---(end of broadcast)---
TIP 5
--- Tom Lane <[EMAIL PROTECTED]> wrote:
>
> I can't help thinking you are looking at generalized
> system
> instability. Maybe someone knocked a few cables
> loose while
> installing new network hardware?
Database server/storage instability or network
instability?
There is no doubt that there
Jeff Amiel <[EMAIL PROTECTED]> writes:
> Even more odd is that a LOCAL pg_dump (from on the
> box) succeeded just fine tonight (after the second
> crash).
That seems to eliminate the theory of a crash due to data corruption
... unless the corruption somehow repaired itself in the intervening
30 mi
>From the logs tonight when the second crash occurred..
Aug 22 20:45:12 db-1 postgres[5805]: [ID 748848
local0.info] [6-1] 2007-08-22 20:45:12 CDT LOG:
received smart shutdown request
Aug 22 20:45:12 db-1 postgres[5805]: [ID 748848
local0.info] [7-1] 2007-08-22 20:45:12 CDT LOG:
server proce
Fairly new (less than a week) install.
"PostgreSQL 8.2.4 on i386-pc-solaris2.10, compiled by
GCC gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)"
database size around 43 gigabytes.
2 attempts at a pg_dump across the network caused the
database to go down...
The first time I thought it was beca