Search Postgresql Archives

Re: Vacuum as "easily obtained" locks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux