From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Janning Vygen" <vygen(at)gmx(dot)de> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: pg_xlog disk full error, i need help |
Date: | 2005-03-28 16:06:24 |
Message-ID: | 29238.1112025984@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Janning Vygen" <vygen(at)gmx(dot)de> writes:
> My disk was running full with 100 GB (!) of data/pg_xlog/ files.
The only way for pg_xlog to bloat vastly beyond what it's supposed to be
(which is to say, about twice your checkpoint_segments setting) is if
checkpoints are somehow blocked from happening. The only mechanism I
know about for that is that in 7.4.* (maybe 7.3.* too) a very large
btree CREATE INDEX or REINDEX operation can block checkpoints until it
completes. Did you have something like that going on?
Anyway, replaying that much log is gonna take awhile :-(. I think you
have only two choices:
1. Grin and bear it.
2. Kill the replay process, then use pg_resetxlog to throw away the xlog.
Then pray you didn't lose anything critical by doing so.
If you know that there was nothing going on except the supposed index
build, then you can be pretty sure that #2 will lose nothing except the
incomplete index, so it might be a workable alternative.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Richard_D_Levine | 2005-03-28 16:11:03 | US DoD FOSS Recommendation |
Previous Message | Oleg Bartunov | 2005-03-28 15:51:32 | Re: Parallel Query should be a top priority |