Thread: determining which table is being vacuumed by autovacuum

Hi List;


I want to determine which table is being vacuumed.

I ran this:

postgres=# select procpid, current_query from pg_stat_activity where
current_query = 'VACUUM';
 procpid | current_query
---------+---------------
    9902 | VACUUM
(1 row)



Then I ran this:

postgres=# select relation from pg_locks where pid = 9902;
 relation
-----------
  82097999
 143763216
 143763215
 143763193
 143763193
 143763217
(7 rows)



However none of these seem to have a corresponding pg_class oid, see the below
queries:

postgres=# select relation::regclass from pg_locks where pid = 9902;
 relation
-----------
 82097999
 143763216
 143763215
 143763193
 143763193
 143763217
(7 rows)

postgres=# select relname from pg_class where oid in (select relation from
pg_locks where pid = 9902);
 relname
---------
(0 rows)





2 questions:

1) Is this normal, as in are there normally relation values in pg_locks that
are not meant to correspond to a pg_class oid (i.e. a table name)

2) Is this the best way to determine which table is currently being vacuumed?

Thanks in advance...

Kevin Kempter <kevin@kevinkempterllc.com> writes:
> Then I ran this:

> postgres=# select relation from pg_locks where pid = 9902;
>  relation
> -----------
>   82097999
>  143763216
>  143763215
>  143763193
>  143763193
>  143763217
> (7 rows)

> However none of these seem to have a corresponding pg_class oid, see
> the below queries:

This most likely means that the vacuum is happening in a different
database than you are looking in.  Did you check
pg_stat_activity.datname?

            regards, tom lane

On Wednesday 22 August 2007 22:10:05 Tom Lane wrote:
> Kevin Kempter <kevin@kevinkempterllc.com> writes:
> > Then I ran this:
> >
> > postgres=# select relation from pg_locks where pid = 9902;
> >  relation
> > -----------
> >   82097999
> >  143763216
> >  143763215
> >  143763193
> >  143763193
> >  143763217
> > (7 rows)
> >
> > However none of these seem to have a corresponding pg_class oid, see
> > the below queries:
>
> This most likely means that the vacuum is happening in a different
> database than you are looking in.  Did you check
> pg_stat_activity.datname?
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster


I sent this once but it never showed up on the list, so just to make sure it
gets into the archives here it is again:


All;

I had a brain-dead moment (user-error). It turns out that the above queries do
work fine when they're both run against the same database.