Re: Vacuum as "easily obtained" locks
От | Eduardo Morras |
---|---|
Тема | Re: Vacuum as "easily obtained" locks |
Дата | |
Msg-id | 4D7F86D501CCE56A@ обсуждение исходный текст |
Ответ на | Re: Vacuum as "easily obtained" locks (Michael Graham <mgraham@bloxx.com>) |
Ответы |
Re: Vacuum as "easily obtained" locks
|
Список | pgsql-general |
At 16:35 03/08/2011, Michael Graham wrote: >Yeah it said it last ran yesterday (and is currently running now), but I >did I notice in the log: > >2011-08-02 19:43:35 BST ERROR: canceling autovacuum task >2011-08-02 19:43:35 BST CONTEXT: automatic vacuum of table >"traffic.public.logdata5queue" > >Which is interesting if not particularly useful. > > > While you are running a test, you could keep an eye on the log to see > > if you get any of those messages. I think that would indicate > > autovacuum could not get a lock. You can also watch pg_stat_activity > > during the test, current_query will show you what table is being > > vacuumed. > >I'm pretty certain the autovacuumer is running while the test is on >going what I can't work out is under what circumstances it will be able >to return unused space to the OS in when it can't. One question, while you run your tests, does "IDLE IN TRANSACTION" messages happen? If you run your tests with a permanent connection to database, the tables are locked and autovacuum cannot work. I saw this with hibernate a queue... don't remember now, that stores data in postgres without closing connection. HTH
В списке pgsql-general по дате отправления: