Re: Auto vacuum not running -- Could not bind socket for statistics collector
От | Tim Schäfer |
---|---|
Тема | Re: Auto vacuum not running -- Could not bind socket for statistics collector |
Дата | |
Msg-id | 356884833.3017.1417595789421.open-xchange@app08.ox.hosteurope.de обсуждение исходный текст |
Ответ на | Re: Auto vacuum not running -- Could not bind socket for statistics collector (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Auto vacuum not running -- Could not bind socket for
statistics collector
Re: Auto vacuum not running -- Could not bind socket for statistics collector |
Список | pgsql-general |
Hi, > On December 2, 2014 at 4:51 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > =?UTF-8?Q?Tim_Sch=C3=A4fer?= <ts+ml@rcmd.org> writes: > > After starting the server with pg_ctl start, I get the following entries in > > the > > logs: > > > 2014-12-02 15:27:36 CET LOG: could not bind socket for statistics > > collector: Cannot assign requested address > > 2014-12-02 15:27:36 CET LOG: disabling statistics collector for lack of > > working socket > > Yes, this will break autovacuum, because it won't have any way to find out > what it should vacuum. The cause probably is a DNS issue: "localhost" > isn't resolving to anything sensible. "dig localhost" on the command line > might offer some insight. thanks for your answer. Here is my full 'dig localhost' from the database server: ~/data> dig localhost ; <<>> DiG 9.9.4-rpz2.13269.14-P2 <<>> localhost ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10157 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;localhost. IN A ;; ANSWER SECTION: localhost. 604800 IN A 127.0.0.1 ;; AUTHORITY SECTION: localhost. 604800 IN NS localhost. ;; ADDITIONAL SECTION: localhost. 604800 IN AAAA ::1 ;; Query time: 1 msec ;; SERVER: 192.168.185.11#53(192.168.185.11) ;; WHEN: Wed Dec 03 09:24:53 CET 2014 ;; MSG SIZE rcvd: 96 Looks fine to me. Or is there something wrong with it? And are you sure pgsql is unhappy with localhost? It would be great if I definitely knew the address it is trying to bind. Is there a way to tell? Thanks again & greetings, -- Tim
В списке pgsql-general по дате отправления: