Обсуждение: A change in the Debian install
Hello, Postgres is started via pg_ctl and NOT systemd. Below are the log entries when version 9.6.2-1 is started. 2017-04-04 07:15:27 AESTLOG: database system was shut down at 2017-04- 03 13:08:27 AEST 2017-04-04 07:15:28 AESTLOG: MultiXact member wraparound protections are now enabled 2017-04-04 07:15:28 AESTLOG: database system is ready to accept connections 2017-04-04 07:15:28 AESTLOG: autovacuum launcher started Upgraded to version 9.6.2-2 and these are the log entries on start-up:- 2017-04-05 08:03:29 AESTLOG: test message did not get through on socket for statistics collector 2017-04-05 08:03:29 AESTLOG: disabling statistics collector for lack of working socket 2017-04-05 08:03:29 AESTWARNING: autovacuum not started because of misconfiguration 2017-04-05 08:03:29 AESTHINT: Enable the "track_counts" option. 2017-04-05 08:03:29 AESTLOG: database system was shut down at 2017-04- 04 13:05:46 AEST 2017-04-05 08:03:30 AESTLOG: MultiXact member wraparound protections are now enabled 2017-04-05 08:03:30 AESTLOG: database system is ready to accept connections It is ignoring the PGDATA path and obtaining postgresql.conf from /etc/postgresql/9.6/main. Removed all the Postgres conf files from the /etc path and it is back working as intended. Is this just something the Debian package maintainers have done or do we have to alter the start-up scripts to specify the config_file setting? The doco says "By default, all three configuration files are stored in the database cluster's data directory." which IMHO means where PGDATA is pointing. Has anybody else struck this issue? Cheers, Rob
rob stone <floriparob@gmail.com> writes:
> Upgraded to version 9.6.2-2 and these are the log entries on start-up:-
> 2017-04-05 08:03:29 AESTLOG: test message did not get through on
> socket for statistics collector
This is not something that would be affected by any Postgres setting;
the stats collector always depends on a loopback TCP connection to
"localhost", and has done so since day one. If it was working before,
you need to look at what you changed related to network and firewall
configuration. These symptoms looks like some kernel firewall rule
deciding to block local-loopback TCP traffic, for what that's worth.
(But ... these statements are based on an assumption of out-of-the-
box Postgres behavior. I would not exactly put it past the Debian
packagers to have decided to change this for reasons of their own,
and their track record of telling us about such decisions is many
miles south of abysmal. So you might look at whatever patches
are in the Debian package to see if there's anything touching
pgstat.c's socket-setup logic.)
regards, tom lane
On 04/05/2017 08:03 PM, rob stone wrote: > Hello, > > Postgres is started via pg_ctl and NOT systemd. > Below are the log entries when version 9.6.2-1 is started. > > 2017-04-04 07:15:27 AESTLOG: database system was shut down at 2017-04- > 03 13:08:27 AEST > 2017-04-04 07:15:28 AESTLOG: MultiXact member wraparound protections > are now enabled > 2017-04-04 07:15:28 AESTLOG: database system is ready to accept > connections > 2017-04-04 07:15:28 AESTLOG: autovacuum launcher started > > > Upgraded to version 9.6.2-2 and these are the log entries on start-up:- What repos are you using, the Debian or the PGDG one? I guess the question I should really ask is, are you using a repo or some other method to upgrade? > > 2017-04-05 08:03:29 AESTLOG: test message did not get through on > socket for statistics collector > 2017-04-05 08:03:29 AESTLOG: disabling statistics collector for lack > of working socket > 2017-04-05 08:03:29 AESTWARNING: autovacuum not started because of > misconfiguration > 2017-04-05 08:03:29 AESTHINT: Enable the "track_counts" option. > 2017-04-05 08:03:29 AESTLOG: database system was shut down at 2017-04- > 04 13:05:46 AEST > 2017-04-05 08:03:30 AESTLOG: MultiXact member wraparound protections > are now enabled > 2017-04-05 08:03:30 AESTLOG: database system is ready to accept > connections > > It is ignoring the PGDATA path and obtaining postgresql.conf from > /etc/postgresql/9.6/main. > > Removed all the Postgres conf files from the /etc path and it is back > working as intended. > > > Is this just something the Debian package maintainers have done or do > we have to alter the start-up scripts to specify the config_file > setting? > > The doco says "By default, all three configuration files are stored in > the database cluster's data directory." which IMHO means where PGDATA > is pointing. That is packaging dependent. When using the Debian/Ubuntu postgresql-common system the postgresql.conf will be in /etc/postgresql/version/cluster_name/ > > Has anybody else struck this issue? > > Cheers, > Rob > > > -- Adrian Klaver adrian.klaver@aklaver.com