R: VACUUM FULL ANALYSE hanging

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(dot)bartolini(at)comune(dot)prato(dot)it - www.comune.prato.it - www.htminer.it

-----Messaggio originale-----
Da: Scott Marlowe [mailto:smarlowe(at)g2switchworks(dot)com]
Inviato: mercoledì 2 maggio 2007 17.41
A: Gabriele Bartolini
Cc: pgsql-admin(at)postgresql(dot)org
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.