Thread: skipping analyze of "table1" --- lock not available?

skipping analyze of "table1" --- lock not available?

From
AI Rumman
Date:
Could someone please tell me why I am getting these in my log:

2014-06-23 00:00:00.031 CDT [11379][@] : [1-1]LOG:  skipping analyze of "table1" --- lock not available
2014-06-23 00:00:00.056 CDT [11380][@] : [1-1]LOG:  skipping analyze of "table1" --- lock not available
2014-06-23 00:00:00.081 CDT [11381][@] : [1-1]LOG:  skipping analyze of "table1" --- lock not available
2014-06-23 00:00:00.106 CDT [11382][@] : [1-1]LOG:  skipping analyze of "table1" --- lock not available
2014-06-23 00:00:00.131 CDT [11383][@] : [1-1]LOG:  skipping analyze of "table1" --- lock not available
2014-06-23 00:00:00.156 CDT [11384][@] : [1-1]LOG:  skipping analyze of "table1" --- lock not available
2014-06-23 00:00:00.181 CDT [11385][@] : [1-1]LOG:  skipping analyze of "table1" --- lock not available
2014-06-23 00:00:00.206 CDT [11386][@] : [1-1]LOG:  skipping analyze of "table1" --- lock not available
2014-06-23 00:00:00.231 CDT [11387][@] : [1-1]LOG:  skipping analyze of "table1" --- lock not available


Thanks.

Re: skipping analyze of "table1" --- lock not available?

From
Kevin Grittner
Date:
AI Rumman <rummandba@gmail.com> wrote:

> Could someone please tell me why I am getting these in my log:
>
> 2014-06-23 00:00:00.031 CDT [11379][@] : [1-1]LOG:  skipping analyze of "table1" --- lock not available

Enough activity has accumulated on table1 that it is due for new
statistics, but when autovacuum tried to gather them there was a
conflicting lock on the table.  This could be from any of the
following statements being run on table1 or having been run on
table1 in a transaction which is still open:

VACUUM
ANALYZE
CREATE INDEX
ALTER TABLE
DROP TABLE
TRUNCATE
CLUSTER
LOCK TABLE

If you look at the pg_locks and pg_stat_activity system views while
this is happening, you can probably figure out what the specific
cause is.  Note that this is at the LOG level, not at WARNING,
ERROR, or anything more severe; if it only happens occasionally or
for relatively short periods of time, especially periods when the
above commands may be running, there is no reason to worry.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


skipping analyze of "table1" --- lock not available?

From
Jeff Janes
Date:
On Monday, June 23, 2014, AI Rumman <rummandba@gmail.com> wrote:
Could someone please tell me why I am getting these in my log:

2014-06-23 00:00:00.031 CDT [11379][@] : [1-1]LOG:  skipping analyze of "table1" --- lock not available
2014-06-23 00:00:00.056 CDT [11380][@] : [1-1]LOG:  skipping analyze of "table1" --- lock not available
2014-06-23 00:00:00.081 CDT [11381][@] : [1-1]LOG:  skipping analyze of "table1" --- lock not available
2014-06-23 00:00:00.106 CDT [11382][@] : [1-1]LOG:  skipping analyze of "table1" --- lock not available
2014-06-23 00:00:00.131 CDT [11383][@] : [1-1]LOG:  skipping analyze of "table1" --- lock not available
2014-06-23 00:00:00.156 CDT [11384][@] : [1-1]LOG:  skipping analyze of "table1" --- lock not available
2014-06-23 00:00:00.181 CDT [11385][@] : [1-1]LOG:  skipping analyze of "table1" --- lock not available
2014-06-23 00:00:00.206 CDT [11386][@] : [1-1]LOG:  skipping analyze of "table1" --- lock not available
2014-06-23 00:00:00.231 CDT [11387][@] : [1-1]LOG:  skipping analyze of "table1" --- lock not available

It means that something has a higher-than-typical lock on table1 which is blocking the analyze.  It could be a CLUSTER or an REINDEX or something like that, but my best guess is that it is an autovacuum on that table that is doing it.

Based on the low time between the messages, I'd also speculate that there is an autovacuum in the same database being done for anti-wrap around purposes, and you are falling afoul of this: 

It is probably nothing to worry about.   The presence of LOG messages which have not been specifically requested doesn't mean you have a problem, it just means that if you *do* have an empirical problem, this would be a good place to start investigating it.

Cheers,

Jeff