Re: VACUUM WARNING: skipping "pg_statistic" --- only table or database owner can vacuum it

From: Ray Stell <stellr(at)cns(dot)vt(dot)edu>
To: pgsql-admin(at)postgresql(dot)org
Subject: Re: VACUUM WARNING: skipping "pg_statistic" --- only table or database owner can vacuum it
Date: 2010-02-09 22:39:52
Message-ID: 20100209223952.GA11857@cns.vt.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

On Sat, Jan 30, 2010 at 09:59:36AM -0500, Ray Stell wrote:
> Running 8.2.15 on RHEL4 the log reports this from autovacuum along with
> other pg_ tables:
>
> VACUUM WARNING: skipping "pg_database" --- only table or database owner can vacuum it

More logging shows the user generating the msg is not superuser. The user
is named "admin," as it is an application administrator and it chokes
on all the rels in information_schema and pg_catalog.

fms=# select * from pg_user where usename = 'admin';
usename | usesysid | usecreatedb | usesuper | usecatupd | passwd | valuntil | useconfig
---------+----------+-------------+----------+-----------+----------+----------+-----------
admin | 16385 | f | f | f | ******** | |
(1 row)

Superuser owns these rels:

fms=# select * from pg_tables where tablename = 'sql_sizing';
schemaname | tablename | tableowner | tablespace | hasindexes | hasrules | hastriggers
--------------------+------------+------------+------------+------------+----------+-------------
information_schema | sql_sizing | postgres | | f | f | f
(1 row)

This vacuum.c if clause that gets to the warning msg:

if (!(pg_class_ownercheck(RelationGetRelid(onerel), GetUserId()) ||
(pg_database_ownercheck(MyDatabaseId, GetUserId()) && !onerel->rd_rel->relisshared)))

The following printf in the vacuum.c clause shows all is well, but
raises some questions:

1 pg_class_ownercheck(RelationGetRelid(onerel), GetUserId())=0
2 RelationGetRelid(onerel)=sql_sizing
3 GetUserId()=16385
4 pg_database_ownercheck(MyDatabaseId, GetUserId())=0
5 MyDatabaseId=16384
6 onerel->rd_rel->relisshared=0

Is autovacuum handing all users off to vacuum all rels? Even those
it does not own? Perhaps "admin" an unfortunate usename choice?

Thanks.

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Keith Gabryelski 2010-02-10 00:26:25 pg_migrator from 32bit to 64bit arch -- does it work? caveats?
Previous Message Dimitri Fontaine 2010-02-09 10:39:08 Re: Best Replication Tool