Am Montag, 28. März 2005 18:06 schrieb Tom Lane: > "Janning Vygen" <[EMAIL PROTECTED]> 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?
first of all i have 7.4 running. A "CLUSTER" was running which to me is somewhat similiar to REINDEX, isn't it? And the night before i killed -9 my nightly vacuum process which did not return after 6 hours or so. first i tried to stop the postmaster with the init.d script, which didnt worked at all. i think that killing this vacuum process was not a good idea. 24 hours after killing this process this ugly xlog thing happend while executing "CLUSTER". And the pg_dump right before "CLUSTER" did work fine. Besides 100 GB of xlog, another strange thing that i had about 42 GB in directory data/base. And it should be about 4 GB and i vacuum an cluster every night. > Anyway, replaying that much log is gonna take awhile :-(. I think you > have only two choices: > 1. Grin and bear it. i tried for several hours. > 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. i killed the process and used a database backup from just before the error occurred. > 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. When it comes to trouble with postgresql i always have the feeling of not knowing enough stuff which is NOT inside the docs. I had another ugly situation a year ago and when in trouble it's very difficult to act calm. Isnt' there more information about "Troubleshooting" than reading postgresql code and archives? I am not an expert DBA (i wouldn't call me a DBA at all besides the fact that i am actually doing the administration). But i am willing to learn. kind regards, janning -- PLANWERK 6 websolutions Herzogstraße 85, 40215 Düsseldorf Tel.: 0211-6015919 Fax: 0211-6015917 http://www.planwerk6.de ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
