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  (John R Pierce <pierce@hogranch.com>)
Список 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 по дате отправления:

Предыдущее
От: Jerry Sievers
Дата:
Сообщение: Re: Vacuum as "easily obtained" locks
Следующее
От: John R Pierce
Дата:
Сообщение: Re: Vacuum as "easily obtained" locks