Josh Berkus <[EMAIL PROTECTED]> writes:
> One thing I am puzzled by is the "D" status on the VACUUM process.
Disk I/O wait state, no? Pretty much what I'd expect for VACUUM ...
regards, tom lane
---(end of broadcast)---
TIP
Tom,
> I think it just needed more time. VACUUM goes to great lengths to be
> crash-safe. I doubt that a "fast stop" could have left the database
> in a corrupted state.
OK, that's reasuring. I would have liked to give the process more time, but
with users waiting
One thing I am puzzle
Josh Berkus <[EMAIL PROTECTED]> writes:
> Does this sound like a crash during VACUUM, or just like it needed more time?
I think it just needed more time. VACUUM goes to great lengths to be
crash-safe. I doubt that a "fast stop" could have left the database
in a corrupted state.
It is entirely l
Folks,
I've a 7.2.4 report-generation database that has been growing for some time,
resuting in the nightly VACUUM FULL ANALYZE taking longer and longer. (most
of the data is copied nightly from other systems, so use of FSM is not very
effective).
The problem is that the nightly admin scripts
Hi Tom,
where can i find the -n option in pg_dump. Is there any special version?
I have 7.3.3.
Regards,
Daniel
-Ursprungliche Nachricht-
Von: Tom Lane [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 1. Juli 2003 15:44
An: Curt Sampson
Cc: [EMAIL PROTECTED]
Betreff: Re: [BUGS] pg_dump -t
