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
[EMAIL PROTECTED] - www.comune.prato.it - www.htminer.it
-----Messaggio originale-----
Da: Scott Marlowe [mailto:[EMAIL PROTECTED]
Inviato: mercoledì 2 maggio 2007 17.41
A: Gabriele Bartolini
Cc: [email protected]
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.
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
