Jeremy Haile wrote: > > > Once you free some space on the data partition and restart, you should > > > be good to go --- there will be no loss of committed transactions, since > > > all the operations are in pg_xlog. Might take a little while to replay > > > all that log though :-( > > > > Amazing that all works. What I did not see is confirmation from the > > user that the data directory filled up _before_ pg_xlog filled up. > > After I freed up space on the pg_xlog partition and restarted, it took > some time to replay all of the log (15-20 minutes) and everything > recovered with no data corruption! However, the theory about the data > partition filling up first didn't happen in my case. The data partition > was (and still is) less than 50% utilized. My pg_xlog files typically > run around 400MB, but with the long running update filled up the entire > 10GB partition. (which is now a 70 GB partition) > > So, I'm still not sure what caused the problem. When I get back to work > (or maybe sooner), I'll take a look in the PG logs and post anything > that looks suspicious here. Thanks for all of your comments and > suggestions. Even though I haven't figured out the root of the problem > yet, they've been very informative. The bottom line is that we know of now cases where a long-running transaction would delay recycling of the WAL files, so there is certainly something not understood here. -- Bruce Momjian bruce@xxxxxxxxxx EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
