Re: Autovacuum of pg_database - Mailing list pgsql-admin

Dne 5.5.2016 v 17:16 Ondřej Světlík napsal(a):
> Hello again,
>
> we have another strange problem with autovacuum. The process goes well
> until it reaches the table pg_database (in some databases, not all),
> then it loops over it forever  (until I run vacuum full analyze on that
> table, simple vacuum doesn't help):
>
> 2016-05-05 17:13:33 CEST  34818LOG:  automatic vacuum of table
> "somedatabase.pg_catalog.pg_database": index scans: 0
>      pages: 0 removed, 233 remain
>      tuples: 0 removed, 5817 remain, 0 are dead but not yet removable
>      buffer usage: 87 hits, 0 misses, 0 dirtied
>      avg read rate: 0.000 MB/s, avg write rate: 0.000 MB/s
>      system usage: CPU 0.00s/0.00u sec elapsed 0.00 sec
> 2016-05-05 17:13:33 CEST  34819LOG:  automatic vacuum of table
> "somedatabase.pg_catalog.pg_database": index scans: 0
>      pages: 0 removed, 233 remain
>      tuples: 0 removed, 5817 remain, 0 are dead but not yet removable
>      buffer usage: 87 hits, 0 misses, 0 dirtied
>      avg read rate: 0.000 MB/s, avg write rate: 0.000 MB/s
>      system usage: CPU 0.00s/0.00u sec elapsed 0.00 sec
> 2016-05-05 17:13:33 CEST  34820LOG:  automatic vacuum of table
> "somedatabase.pg_catalog.pg_database": index scans: 0
>      pages: 0 removed, 233 remain
>      tuples: 0 removed, 5817 remain, 0 are dead but not yet removable
>      buffer usage: 87 hits, 0 misses, 0 dirtied
>      avg read rate: 0.000 MB/s, avg write rate: 0.000 MB/s
>      system usage: CPU 0.00s/0.00u sec elapsed 0.00 sec
> 2016-05-05 17:13:34 CEST  34821LOG:  automatic vacuum of table
> "somedatabase.pg_catalog.pg_database": index scans: 0
>      pages: 0 removed, 233 remain
>      tuples: 0 removed, 5817 remain, 0 are dead but not yet removable
>      buffer usage: 87 hits, 0 misses, 0 dirtied
>      avg read rate: 0.000 MB/s, avg write rate: 0.000 MB/s
>      system usage: CPU 0.00s/0.00u sec elapsed 0.00 sec
>
> Not sure if it's a bug or I'm doing something wrong.
>
> Thanks in advance,
>
> Ondřej


Another part of log shows, that the process tries pg_database twice,
than it does one other table and than back to pg_database for the rest
of our days:

2016-05-05 17:16:56 CEST  36675LOG:  automatic vacuum of table
"someotherdb.pg_catalog.pg_database": index scans: 0
    pages: 0 removed, 233 remain
    tuples: 0 removed, 5817 remain, 0 are dead but not yet removable
    buffer usage: 36 hits, 50 misses, 2 dirtied
    avg read rate: 3.277 MB/s, avg write rate: 0.131 MB/s
    system usage: CPU 0.00s/0.00u sec elapsed 0.11 sec
2016-05-05 17:16:56 CEST  36676LOG:  automatic vacuum of table
"someotherdb.pg_catalog.pg_database": index scans: 0
    pages: 0 removed, 233 remain
    tuples: 0 removed, 5817 remain, 0 are dead but not yet removable
    buffer usage: 68 hits, 18 misses, 0 dirtied
    avg read rate: 2.563 MB/s, avg write rate: 0.000 MB/s
    system usage: CPU 0.00s/0.00u sec elapsed 0.05 sec
2016-05-05 17:16:56 CEST  36674LOG:  automatic vacuum of table
"someotherdb.pg_toast.pg_toast_2618": index scans: 1
    pages: 58 removed, 50 remain
    tuples: 141 removed, 219 remain, 0 are dead but not yet removable
    buffer usage: 151 hits, 192 misses, 73 dirtied
    avg read rate: 2.728 MB/s, avg write rate: 1.037 MB/s
    system usage: CPU 0.00s/0.00u sec elapsed 0.54 sec
2016-05-05 17:16:56 CEST  36677LOG:  automatic vacuum of table
"someotherdb.pg_catalog.pg_database": index scans: 0
    pages: 0 removed, 233 remain
    tuples: 0 removed, 5817 remain, 0 are dead but not yet removable
    buffer usage: 86 hits, 0 misses, 0 dirtied
    avg read rate: 0.000 MB/s, avg write rate: 0.000 MB/s
    system usage: CPU 0.00s/0.00u sec elapsed 0.01 sec

Ondřej