Re: vacuumdb question/problem
| От | David Ondrejik |
|---|---|
| Тема | Re: vacuumdb question/problem |
| Дата | |
| Msg-id | 4E208B57.6010401@noaa.gov обсуждение исходный текст |
| Ответ на | Re: vacuumdb question/problem (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: vacuumdb question/problem
Re: vacuumdb question/problem |
| Список | pgsql-admin |
Tom, It was not consuming any CPU time. I found that another process on the machine failed. That process was trying to write to a different table (not the one I was vacuuming) in the database and that table was locked (not sure why). It produced thousands of errors which caused the log files to grow large enough that the entire disk was filled, and this brought everything to a halt. So I had to kill my process, recover disk space and get the machine back in working condition for the weekend. I guess I will attempt to do the full vacuum again next week. I am still wondering how the vacuum process actually works. When it throws the output lines that show how many rows are recoverable/nonremovable, does this mean that the vacuum has completed? Or do those output lines show the vacuum has scanned through the database...found what what it is going to recover and then takes on the vacuum process? Thanks, Dave Tom Lane said the following on 7/15/2011 1:12 PM: > Simon Riggs<simon@2ndQuadrant.com> writes: >> On Fri, Jul 15, 2011 at 5:10 PM, David Ondrejik<David.Ondrejik@noaa.gov> wrote: >>> Since then, the process has continued to run (for about 20 hrs) without any >>> additional information being returned. >> Probably locked behind another long running task that is holding a buffer pin. > That's possible, or it could be busy vacuuming some (really large?) > index. Is the process actually busy, as in consuming CPU time according > to top or other process monitoring tool? > > regards, tom lane
Вложения
В списке pgsql-admin по дате отправления: