Hi guys, thanks for your answer. Unfortunately I have no superuser privileges on that server, but I have tried to look it up closely with our administrator today. I launched the VACUUM FULL ANALYSE command last night on a table, and it is still running. Now, I want to finish it and see how long it took. It is a test I want to do. The process is not idle, we have 'straced' it and here it's the output: postgres 9178 9.2 10.9 527384 443476 ? Ds May03 75:37 \_ postgres: htminer htminer [local] VACUUM > strace -i -p 9178 Process 9178 attached - interrupt to quit [ 339e0c6902] lseek(55, 1067171840, SEEK_SET) = 1067171840 [ 339e0b9302] write(55, "\317\0\0\0h\37\353\331\1\0\0\0l\1\220\32\360\37\3 \340"..., 8192) = 8192 [ 339e0c6902] lseek(31, 31145984, SEEK_SET) = 31145984 [ 339e0b9272] read(31, "m\0\0\0\320\22V\36\1\0\0\0\240\5\310\t\360\37\3 \340\237"..., 8192) = 8192 [ 339e0c6902] lseek(31, 31309824, SEEK_SET) = 31309824 [ 339e0b9272] read(31, "\317\0\0\0\310\26\353\331\1\0\0\0\350\4\240\f\360\37\3"..., 8192) = 8192 [ 339e0c6902] lseek(32, 667787264, SEEK_SET) = 667787264 [ 339e0b9272] read(32, "\301\0\0\0PI\t\27\1\0\0\0\34\0\330\37\360\37\3 \350\237"..., 8192) = 8192 [ 339e0c6902] lseek(34, 157900800, SEEK_SET) = 157900800 [ 339e0b9272] read(34, "\317\0\0\0P\3725\327\1\0\0\0\260\5\210\t\360\37\3 \350"..., 8192) = 8192 If you are interested - and may be useful for comparisons - I will let you know the results. The tables are locked (I looked at pg_lock): htminer=> select * from pg_locks where pid = 9178; locktype | database | relation | page | tuple | transactionid | classid | objid | objsubid | transaction | pid | mode | granted ---------------+----------+----------+------+-------+---------------+---------+-------+----------+-------------+------+---------------------+--------- relation | 16415 | 199381 | | | | | | | 64899160 | 9178 | RowExclusiveLock | t relation | 16415 | 199381 | | | | | | | 64899160 | 9178 | AccessExclusiveLock | t relation | 16415 | 199385 | | | | | | | 64899160 | 9178 | RowExclusiveLock | t relation | 16415 | 199385 | | | | | | | 64899160 | 9178 | AccessExclusiveLock | t transactionid | | | | | 64899160 | | | | 64899160 | 9178 | ExclusiveLock | t relation | 16415 | 199142 | | | | | | | 64899160 | 9178 | RowExclusiveLock | t relation | 16415 | 199142 | | | | | | | 64899160 | 9178 | AccessExclusiveLock | t relation | 16415 | 199382 | | | | | | | 64899160 | 9178 | RowExclusiveLock | t relation | 16415 | 199382 | | | | | | | 64899160 | 9178 | AccessExclusiveLock | t relation | 16415 | 199383 | | | | | | | 64899160 | 9178 | RowExclusiveLock | t relation | 16415 | 199383 | | | | | | | 64899160 | 9178 | AccessExclusiveLock | t relation | 16415 | 199386 | | | | | | | 64899160 | 9178 | RowExclusiveLock | t relation | 16415 | 199386 | | | | | | | 64899160 | 9178 | AccessExclusiveLock | t relation | 16415 | 198716 | | | | | | | 64899160 | 9178 | AccessExclusiveLock | t relation | 16415 | 199384 | | | | | | | 64899160 | 9178 | RowExclusiveLock | t relation | 16415 | 199384 | | | | | | | 64899160 | 9178 | AccessExclusiveLock | t It should be alright. I am waiting for the results. Thank you for your nice answers. Ciao, Gabriele -- Gabriele Bartolini - Istruttore Informatico - Comune di Prato Sistema Informativo - Servizi di E-Government e Open-Source g.bartolini@xxxxxxxxxxxxxxx - www.comune.prato.it - www.htminer.it -----Messaggio originale----- Da: Scott Marlowe [mailto:smarlowe@xxxxxxxxxxxxxxxxx] Inviato: mercoledì 2 maggio 2007 17.41 A: Gabriele Bartolini Cc: pgsql-admin@xxxxxxxxxxxxxx Oggetto: Re: [ADMIN] VACUUM FULL ANALYSE hanging On Wed, 2007-05-02 at 05:05, Gabriele Bartolini wrote: > Hi guys, > > I am having problems with freeing disk space after a massive delete > operation on a table that had approximately 80 million record. I ran > the following command, by setting the vacuum memory to approximately a > GigaByte: > > SET vacuum_mem TO 1024000 > VACUUM FULL ANALYSE VERBOSE oltp.requests > > Here is what I get: SNIP > DETAIL: 8211835 index row versions were removed. > 73821 index pages have been deleted, 73821 are currently reusable. > CPU 17.06s/28.14u sec elapsed 319.16 sec. > > But here, the command simply hangs. > > The table description is: Maybe it's hanging, maybe it's just taking a really long time to finish and get back to you. What's vmstat / top /iostat got to say about the machine during this "hang"? IF the I/O or CPU are high, then it's not hung, it's just taking a while.
