Issue enabling track_counts to launch autovacuum in 9.4.5

Поиск
Список
Период
Сортировка
От Derek Elder
Тема Issue enabling track_counts to launch autovacuum in 9.4.5
Дата
Msg-id CAM3xazWDA6asEDDYHcKF_5oSFP4SZj8taVHwSF68wM=VMY7V-A@mail.gmail.com
обсуждение исходный текст
Ответы Re: Issue enabling track_counts to launch autovacuum in 9.4.5  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: Issue enabling track_counts to launch autovacuum in 9.4.5  ("David G. Johnston" <david.g.johnston@gmail.com>)
Список pgsql-general
Good day,

(I apologize if this isn't the right place for this, I haven't used the mailing list before and I'm not a Postgres expert.)

We've run into an issue where autovacuum is not running on one of our servers using 9.4.5.

We discovered that track_counts appears to be off:

2016-03-02 14:58:09 EST [14366][2-1] DEBUG: loaded library "repmgr_funcs"
2016-03-02 14:58:09 EST [14366][3-1] DEBUG: SlruScanDirectory invoking callback on pg_notify/0000
2016-03-02 14:58:09 EST [14366][4-1] DEBUG: removing file "pg_notify/0000"
2016-03-02 14:58:09 EST [14366][5-1] DEBUG: dynamic shared memory system will support 690 segments
2016-03-02 14:58:09 EST [14366][6-1] DEBUG: created dynamic shared memory control segment 1804289383 (5532 bytes)
2016-03-02 14:58:09 EST [14366][7-1] DEBUG: max_safe_fds = 984, usable_fds = 1000, already_open = 6
2016-03-02 14:58:09 EST [14366][8-1] LOG: could not resolve "localhost": Name or service not known
2016-03-02 14:58:09 EST [14366][9-1] LOG: disabling statistics collector for lack of working socket
2016-03-02 14:58:09 EST [14366][10-1] WARNING: autovacuum not started because of misconfiguration
2016-03-02 14:58:09 EST [14366][11-1] HINT: Enable the "track_counts" option.
2016-03-02 14:58:09 EST [14366][12-1] LOG: database system is ready to accept connections
2016-03-02 14:58:10 EST [14366][13-1] DEBUG: forked new backend, pid=14377 socket=8
2016-03-02 14:58:10 EST [14366][14-1] DEBUG: server process (PID 14377) exited with exit code 0
2016-03-02 14:58:10 EST [14366][15-1] DEBUG: forked new backend, pid=14379 socket=8
2016-03-02 14:58:10 EST [14366][16-1] DEBUG: server process (PID 14379) exited with exit code 0
2016-03-02 15:00:01 EST [14366][17-1] DEBUG: forked new backend, pid=14425 socket=8
2016-03-02 15:00:01 EST [14366][18-1] DEBUG: server process (PID 14425) exited with exit code 0
2016-03-02 15:03:26 EST [14366][19-1] DEBUG: postmaster received signal 2
2016-03-02 15:03:26 EST [14366][20-1] LOG: received fast shutdown request
2016-03-02 15:03:26 EST [14366][21-1] LOG: aborting any active transactions
2016-03-02 15:03:26 EST [14366][22-1] DEBUG: cleaning up dynamic shared memory control segment with ID 1804289383


show autovacuum;
autovacuum 
------------
on

show track_counts;
track_counts 
--------------
off



From what I had read, this setting should be on by default. When I checked our other servers I see that track_counts is on and the autovacuum process is working correctly on them. Indeed we don't even have the setting explicitly listed in our postgresql.conf on these servers.

We first tried a simple restart, but that didn't work.

Next I attempted to add track_counts = on to the postgresql.conf and reload it, but the setting doesn't seem to take effect.

I even tried "SET track_counts = on;", but that only works in the current session and doesn't persist.

Is there any other way of turning this setting on or is there something somewhere that could be preventing track_counts from being enabled correctly?

Thank you very much,

Derek

This message, and any documents attached hereto, may contain confidential or proprietary information intended only for the use of the addressee(s) named above or may contain information that is legally  privileged. If you are not the intended addressee, or the person responsible for delivering it to the intended addressee, you are hereby notified that reading, disseminating, distributing or copying this message is strictly prohibited. If you have received this message by mistake, please immediately notify us by replying to the message and delete the original message and any copies immediately thereafter.  Thank you for your cooperation.

В списке pgsql-general по дате отправления:

Предыдущее
От: Joe Conway
Дата:
Сообщение: Re: RLS on catalog tables would be helpful
Следующее
От: Vitaly Burovoy
Дата:
Сообщение: Re: Slow Query - Postgres 9.2