On 09/19/2013 08:42 AM, Kevin Grittner wrote:
The fix accidentally introduced some messages which are confusing,
and caused the statistics from autovacuum to fail to be generated
more often than had previously been the case. These problems should
be fixed in the next minor release. Until then,
Shaun Thomas wrote:
> The first line also seems extremely misleading. a manually
> launched vacuum is not an autovacuum, so why is it complaining
> about an autovacuum? Shouldn't the PID doing the autovacuum emit
> the log message? This all seems a little sketchy.
The table truncation in autovac
On 09/18/2013 11:50 AM, Jeff Janes wrote:
That line is the final line of a multi-line log entry. To know what
it is about, you need to look at the lines before it in the logfile.
Perhaps it is failing to obtain a lock or something.
Thanks for the input, Jeff. The full chunk for that PID (2207
On Tue, Sep 17, 2013 at 1:39 PM, Shaun Thomas wrote:
> Hey,
>
> This is PostgreSQL 9.1.9.
>
>
...
> Apparently something magical happened last Friday, and now analyze is
> broken somehow? Am I missing something, here? The log claims everything
> worked out OK:
>
> 2013-09-17 03:20:37 CDT|STATEME
On 09/18/2013 02:32 AM, Albe Laurenz wrote:
What happens if you run VACUUM (VERBOSE, ANALYZE) manually?
Are the statistics updated?
Are there any warnings?
It looks like running it manually worked fine, but I only ran it on
specific tables that showed up in the list of un-analyzed.
I see no
Shaun Thomas wrote:
> This is PostgreSQL 9.1.9.
>
> So we've had "vacuumdb -avz" launched via cron at 3am for a few years
> now, and recently noticed some queries behaving very badly. While
> checking pg_stat_user_tables, I see this for several hundred of them:
>
> relname |
Hey,
This is PostgreSQL 9.1.9.
So we've had "vacuumdb -avz" launched via cron at 3am for a few years
now, and recently noticed some queries behaving very badly. While
checking pg_stat_user_tables, I see this for several hundred of them:
relname | last_analyze
-
