Hide Forgot
Related forum post: https://www.openshift.com/forums/openshift/warnings-in-postgresql-log Description of problem: postgresql-9.2 cartridge in application brewlog-zgoda.rhcloud.com After startup of cartridge there are following entries in log LOG: could not bind socket for statistics collector: Permission denied LOG: trying another address for the statistics collector LOG: could not bind socket for statistics collector: Permission denied LOG: trying another address for the statistics collector LOG: could not bind socket for statistics collector: Cannot assign requested address LOG: trying another address for the statistics collector LOG: could not bind socket for statistics collector: Cannot assign requested address LOG: disabling statistics collector for lack of working socket WARNING: autovacuum not started because of misconfiguration HINT: Enable the "track_counts" option. PostgreSQL is running without autovacuum process: [brewlog-zgoda.rhcloud.com log]\> ps -A f | grep postgres 1932 ? S 0:00 /opt/rh/postgresql92/root/usr/bin/postgres 1939 ? Ss 0:00 \_ postgres: logger process 1941 ? Ss 0:00 \_ postgres: checkpointer process 1942 ? Ss 0:00 \_ postgres: writer process 1943 ? Ss 0:00 \_ postgres: wal writer process 13879 ? Ss 0:00 \_ postgres: username dbname 127.8.158.130(21744) idle 14161 ? Ss 0:00 \_ postgres: username dbname 127.8.158.130(21775) idle Version-Release number of selected component (if applicable): How reproducible: always in this application Steps to Reproduce: 1. create application with MySQL cartridge and start it 2. add postgresql-9.2 cartridge 3. remove MySQL cartridge 4. restart application observing PostgreSQL log Actual results: PostgreSQL is running without autovacuum process Expected results: Autovacuum process is present Additional info: Tried and not working: - remove postgresql-9.2 cartridge then add it again
Exactly same result can be observed with completely fresh application, just python-2.7 and postgresql-9.2 cartridges.
just wondering about status of this bug. The issue seems to be in how localhost is locked down. Can the internal IP address that is assigned by openshift be added to the list of IP addresses for localhost within /etc/hosts? according to my collegue, Greg Smith, "What PostgreSQL does at startup is ask the OS for the addresses of "localhost" (hard-coded) using the getaddrinfo() system call: https://en.wikipedia.org/wiki/Getaddrinfo It then loops over all the returned addresses until it successfully talks to socket it created, and if all addresses fail it gives the error in the bug report."
Vacuum is pretty important. Can we get this fixed in postgres?
I've created a bug for this w/ Postgres. Postgresql uses a mailing list for bug reports instead of an issue tracker; my report is current pending moderator approval. Will link once it has been posted.
Unfortunately it doesn't look like this is something we'll be able to fix right now. We hope that we'll be able to support it in the future.
Just to connect the dots, here's what Paul filed upstream: http://www.postgresql.org/message-id/20140127183125.26701.88068@wrigleys.postgresql.org Given Tom Lane's response, I don't think postgres is going to change behavior: """" Yeah. In particular, I'd always supposed that a platform that wanted to use some other IP address than 127.0.0.1 for loopback would also be expected to make sure that "localhost" mapped to that other IP address. Otherwise, there simply isn't any way to make network-using software work except random hacks. Frankly, I don't think you're going to get any cooperation from Postgres in adapting to such a broken networking environment as this, and I doubt other upstreams are going to be any more positive about it. """
Paul, you mention in http://www.postgresql.org/message-id/1241903739.14805210.1390938412164.JavaMail.root@redhat.com that using network namespaces in OpenShift is a high priority improvement. Where can its status be tracked ? Is there a bugzilla bug ? Thank you