Add statistics_collector_listen_addresses to fix hard-coding of "localhost"
What Would Happen if I got NO "localhost" entry in my /etc/hosts ?
statistics and autovacuum would be disabled:
# /usr/local/pgsql/bin/postgres -i -p 15432 -D data
LOG: could not resolve "localhost": no address associated with name
LOG: disabling statistics collector for lack of working socket
WARNING: autovacuum not started because of misconfiguration
HINT: Enable the "track_counts" option.
LOG: database system was shut down at 2011-10-27 09:42:14 GMT
LOG: database system is ready to accept connections
So let's fix it:
diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index b468797..fc0f0e7 100644
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -143,6 +143,7 @@ extern bool synchronize_seqscans;
extern bool fullPageWrites;
extern int ssl_renegotiation_limit;
extern char *SSLCipherSuites;
+extern char *StatisticsCollectorListenAddress; #ifdef TRACE_SORT
extern bool trace_sort;
@@ -3052,6 +3053,16 @@ static struct config_string ConfigureNamesString[] =
},
{
+ {"statistics_collector_listen_address", PGC_POSTMASTER, QUERY_TUNING_OTHER,
+ gettext_noop("Sets the host name or IP address for statistics
collector listen to."),
+ NULL
+ },
+ &StatisticsCollectorListenAddress,
+ "localhost",
+ NULL, NULL, NULL
+ },
+
+ {
{"custom_variable_classes", PGC_SIGHUP, CUSTOM_OPTIONS,
gettext_noop("Sets the list of known custom variable classes."),
NULL,
diff --git a/src/backend/postmaster/pgstat.c b/src/backend/postmaster/pgstat.c
index 1d80c31..13ac5a9 100644
--- a/src/backend/postmaster/pgstat.c
+++ b/src/backend/postmaster/pgstat.c
@@ -117,6 +117,7 @@ int pgstat_track_activity_query_size = 1024;
* Built from GUC parameter
* ----------
*/
+char *StatisticsCollectorListenAddress = NULL;
char *pgstat_stat_filename = NULL;
char *pgstat_stat_tmpname = NULL;@@ -323,12 +324,12 @@ pgstat_init(void)
hints.ai_addr = NULL;
hints.ai_canonname = NULL;
hints.ai_next = NULL;
- ret = pg_getaddrinfo_all("localhost", NULL, &hints, &addrs);
+ ret = pg_getaddrinfo_all(StatisticsCollectorListenAddress, NULL,
&hints, &addrs);
if (ret || !addrs)
{
ereport(LOG,
- (errmsg("could not resolve \"localhost\": %s",
- gai_strerror(ret))));
+ (errmsg("could not resolve \"%s\": %s",
+ StatisticsCollectorListenAddress,gai_strerror(ret))));
goto startup_failed;
}@@ -371,7 +372,7 @@ pgstat_init(void)
{
ereport(LOG,
(errcode_for_socket_access(),
- errmsg("could not bind socket for statistics collector: %m")));
+ errmsg("could not bind socket for
statistics_collector_listen_address(%s):
%m",StatisticsCollectorListenAddress)));
closesocket(pgStatSock);
pgStatSock = PGINVALID_SOCKET;
continue;
diff --git a/src/backend/utils/misc/postgresql.conf.sample
b/src/backend/utils/misc/postgresql.conf.sample
index 0f1745f..630b8fd 100644
--- a/src/backend/utils/misc/postgresql.conf.sample
+++ b/src/backend/utils/misc/postgresql.conf.sample
@@ -259,6 +259,7 @@# - Other Planner Options -
+#statistics_collector_listen_address = 'localhost' # should bind to
loopback interface
#default_statistics_target = 100 # range 1-10000
#constraint_exclusion = partition # on, off, or partition
#cursor_tuple_fraction = 0.1 # range 0.0-1.0
Tests:
1.NO localhost entry:
# grep localhost /etc/hosts
# grep statistics_collector_listen_address data/postgresql.conf
#statistics_collector_listen_address = 'localhost' # should bind to
loopback interface
# /usr/local/pgsql/bin/postgres -i -p 5432 -D data
LOG: could not resolve "localhost": no address associated with name
LOG: disabling statistics collector for lack of working socket
WARNING: autovacuum not started because of misconfiguration
HINT: Enable the "track_counts" option.
LOG: database system was shut down at 2011-10-27 09:43:18 GMT
LOG: database system is ready to accept connections
2.Normal circumstance:
# echo 127.0.0.1 localhost > /etc/hosts
# grep localhost /etc/hosts
127.0.0.1 localhost
# grep statistics_collector_listen_address data/postgresql.conf
#statistics_collector_listen_address = 'localhost' # should bind to
loopback interface
# /usr/local/pgsql/bin/postgres -i -p 5432 -D data
LOG: database system was shut down at 2011-10-27 09:48:32 GMT
LOG: database system is ready to accept connections
LOG: autovacuum launcher started
3./etc/hosts misconfigurated:
# echo 127.0.0.44 localhost > /etc/hosts
# grep localhost /etc/hosts
127.0.0.44 localhost
# grep statistics_collector_listen_address data/postgresql.conf
#statistics_collector_listen_address = 'localhost' # should bind to
loopback interface
# /usr/local/pgsql/bin/postgres -i -p 5432 -D data
LOG: could not bind socket for
statistics_collector_listen_address(localhost): Can't 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.
LOG: database system was shut down at 2011-10-27 09:52:10 GMT
LOG: database system is ready to accept connections
4.statistics_collector_listen_address set to IP address:
# grep localhost /etc/hosts
127.0.0.44 localhost
# grep statistics_collector_listen_address data/postgresql.conf
statistics_collector_listen_address = '127.0.0.1' # should bind to
loopback interface
# /usr/local/pgsql/bin/postgres -i -p 5432 -D data
LOG: database system was shut down at 2011-10-27 10:03:56 GMT
LOG: database system is ready to accept connections
LOG: autovacuum launcher started
5.statistics_collector_listen_address misconfigurated:
# grep statistics_collector_listen_address data/postgresql.conf
statistics_collector_listen_address = '127.0.0.W' # should bind to
loopback interface
# /usr/local/pgsql/bin/postgres -i -p 5432 -D data
LOG: could not resolve "127.0.0.W": no address associated with name
LOG: disabling statistics collector for lack of working socket
WARNING: autovacuum not started because of misconfiguration
HINT: Enable the "track_counts" option.
LOG: database system was shut down at 2011-10-27 10:10:12 GMT
LOG: database system is ready to accept connections
6.NO such address:
# grep statistics_collector_listen_address data/postgresql.conf
statistics_collector_listen_address = '127.0.0.77' # should bind to
loopback interface
# /usr/local/pgsql/bin/postgres -i -p 5432 -D data
LOG: could not bind socket for
statistics_collector_listen_address(127.0.0.77): Can't 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.
LOG: database system was shut down at 2011-10-27 10:11:34 GMT
LOG: database system is ready to accept connections
All Tests Passed.
Hi Robert,
On Thursday, October 27, 2011 12:38:02 PM Robert Young wrote:
What Would Happen if I got NO "localhost" entry in my /etc/hosts ?
Why should pg cater for such a broken configuration? Sorry for being harsh but
that seems like it would end in heaps of workarounds.
Andres
But,I think insistence of hard-coding should be even worse than broken
configuration.
And hard-coding should never be a good work ethics of a professional programmer.
Show quoted text
On Thu, Oct 27, 2011 at 12:12, Andres Freund <andres@anarazel.de> wrote:
Hi Robert,
On Thursday, October 27, 2011 12:38:02 PM Robert Young wrote:
What Would Happen if I got NO "localhost" entry in my /etc/hosts ?
Why should pg cater for such a broken configuration? Sorry for being harsh but
that seems like it would end in heaps of workarounds.Andres
On 27.10.2011 15:57, Robert Young wrote:
But,I think insistence of hard-coding should be even worse than broken
configuration.
And hard-coding should never be a good work ethics of a professional programmer.
You're exaggerating. There's nothing wrong hard-coding things like
number of seconds in a minute (60). While it's not as cast in stone as
60 seconds in a minute, I don't see anything wrong with hardcoding that
"localhost" means the local host.
BTW, do we have anything in place to stop any user on the same host to
send bogus stat messages to the stats collector?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
In reality,sometimes something would be wrong if you hard-coding 1
minute as 60 seconds.
Please read:
http://www.openbsd.org/cgi-bin/man.cgi?query=strftime
"The range of seconds is (00-60) instead of (00-59) to allow for the
periodic occurrence of leap seconds."
so,it's a bad habit including hard-coding 1 minute as 60 seconds.
On Thu, Oct 27, 2011 at 13:13, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
Show quoted text
On 27.10.2011 15:57, Robert Young wrote:
But,I think insistence of hard-coding should be even worse than broken
configuration.
And hard-coding should never be a good work ethics of a professional
programmer.You're exaggerating. There's nothing wrong hard-coding things like number of
seconds in a minute (60). While it's not as cast in stone as 60 seconds in a
minute, I don't see anything wrong with hardcoding that "localhost" means
the local host.BTW, do we have anything in place to stop any user on the same host to send
bogus stat messages to the stats collector?--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
BTW, do we have anything in place to stop any user on the same host to
send bogus stat messages to the stats collector?
Yes. Use of the connect() call is supposed to guarantee that we will
only receive packets originating from our own socket address.
As far as the original topic goes, I agree that it seems rather
pointless to worry about systems that fail to resolve "localhost".
Doing so is required by relevant RFCs, eg
http://www.faqs.org/rfcs/bcp/bcp32.html
(That's probably not the only one, it's just the first hit I found
while searching the RFC archives.)
And, given that we've been doing it this way since 2001 without
previous complaints, the number of systems that fail to do it
must be pretty small.
regards, tom lane
On 28/10/11 02:13, Heikki Linnakangas wrote:
On 27.10.2011 15:57, Robert Young wrote:
But,I think insistence of hard-coding should be even worse than broken
configuration.
And hard-coding should never be a good work ethics of a professional
programmer.You're exaggerating. There's nothing wrong hard-coding things like
number of seconds in a minute (60). While it's not as cast in stone as
60 seconds in a minute, I don't see anything wrong with hardcoding
that "localhost" means the local host.BTW, do we have anything in place to stop any user on the same host to
send bogus stat messages to the stats collector?
Actually, a minute is not always 60 seconds, as you can legally have 62
seconds in a minute!
From the documentation for the Java class *java.util.Date*:
[...]
A second is represented by an integer from 0 to 61; the values 60
and 61 occur only for leap seconds and even then only in Java
implementations that actually track leap seconds correctly. Because
of the manner in which leap seconds are currently introduced, it is
extremely unlikely that two leap seconds will occur in the same
minute, but this specification follows the date and time conventions
for ISO C.
[...]
Cheers,
Gavin
Gavin Flower <GavinFlower@archidevsys.co.nz> writes:
Actually, a minute is not always 60 seconds, as you can legally have 62
seconds in a minute!
<pedantry>
There never have been, and will never be, two leap seconds declared in
the same minute --- the need for such would require that the authorities
in charge of declaring leap seconds had been asleep at the switch when
they should have declared the first one, and for awhile afterwards
as well, since the natural spacing of such events is well over a year.
Even if they did get that far behind, they would catch up by declaring
*one* added leap second in several successive opportunities.
The idea that there could need to be 62 seconds in a minute appears to
stem from a typographical error in an ancient version of some Unix
documentation or other (hardly a reference material for timekeeping),
which has been faithfully copied into a bunch of later computer-oriented
standards. But it's wrong, no matter how many places say that. Ask an
astronomer rather than a computer scientist, if you're not convinced.
</pedantry>
regards, tom lane
On 28/10/11 08:53, Tom Lane wrote:
Gavin Flower<GavinFlower@archidevsys.co.nz> writes:
Actually, a minute is not always 60 seconds, as you can legally have 62
seconds in a minute!<pedantry>
There never have been, and will never be, two leap seconds declared in
the same minute --- the need for such would require that the authorities
in charge of declaring leap seconds had been asleep at the switch when
they should have declared the first one, and for awhile afterwards
as well, since the natural spacing of such events is well over a year.
Even if they did get that far behind, they would catch up by declaring
*one* added leap second in several successive opportunities.The idea that there could need to be 62 seconds in a minute appears to
stem from a typographical error in an ancient version of some Unix
documentation or other (hardly a reference material for timekeeping),
which has been faithfully copied into a bunch of later computer-oriented
standards. But it's wrong, no matter how many places say that. Ask an
astronomer rather than a computer scientist, if you're not convinced.</pedantry>
regards, tom lane
Thanks for the explanation!
If we ever really needed the 62 second minute, and the timekeepers were
not sleeping on the job, it would be because of a catastrophic
geological event that would almost certainly mean that the survivors
would be having more pressing concerns... (major earthquakes affect the
speed of the Earth's rotation - microseconds in the case of the last
major Japanese earthquake)
I am just wondering, why "localhost" entry in /etc/hosts is editable
and why 127.0.0.1 not fixed with loopback interface?
should you agree with that we should submit a patch to kernel to
resolve "localhost" to 127.0.0.1 statically need no entry in
/etc/hosts and loopback interface bind to 127.0.0.1 not changeable?
If your answer is NO.
Why you give me this option to configure /etc/hosts or loopback
interface as well as deprive my option which hostname or IP for
statistics_collector to listen on?
Why operating system designed flexible and database system wrote in hard-coding?
Hard-coding is even worse than broken configuration:
1."broken configuration" is still configurable, that is the problem
could be fixed WITHIN the system.
2.hard-coding is NOT configurable, that is the problem must be aided
from OUTSIDE of the system to workaround.
configurable is just better than NOT configurable.
So, why we did no work to make things better, whereas wasting time to
insist hard-coding almost always right?
Show quoted text
On Thu, Oct 27, 2011 at 14:42, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
BTW, do we have anything in place to stop any user on the same host to
send bogus stat messages to the stats collector?Yes. Use of the connect() call is supposed to guarantee that we will
only receive packets originating from our own socket address.As far as the original topic goes, I agree that it seems rather
pointless to worry about systems that fail to resolve "localhost".
Doing so is required by relevant RFCs, eg
http://www.faqs.org/rfcs/bcp/bcp32.html
(That's probably not the only one, it's just the first hit I found
while searching the RFC archives.)And, given that we've been doing it this way since 2001 without
previous complaints, the number of systems that fail to do it
must be pretty small.regards, tom lane
Excerpts from Robert Young's message of vie oct 28 04:11:57 -0300 2011:
I am just wondering, why "localhost" entry in /etc/hosts is editable
and why 127.0.0.1 not fixed with loopback interface?
should you agree with that we should submit a patch to kernel to
resolve "localhost" to 127.0.0.1 statically need no entry in
/etc/hosts and loopback interface bind to 127.0.0.1 not changeable?
If your answer is NO.
Maybe you can define localhost as an IPv6 address.
Why you give me this option to configure /etc/hosts or loopback
interface as well as deprive my option which hostname or IP for
statistics_collector to listen on?
Why operating system designed flexible and database system wrote in hard-coding?
Are you solving a real problem here?
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Fri, Oct 28, 2011 at 3:11 AM, Robert Young <yayooo@gmail.com> wrote:
I am just wondering, why "localhost" entry in /etc/hosts is editable
and why 127.0.0.1 not fixed with loopback interface?
should you agree with that we should submit a patch to kernel to
resolve "localhost" to 127.0.0.1 statically need no entry in
/etc/hosts and loopback interface bind to 127.0.0.1 not changeable?
You're attacking a straw man. Removing /etc/hosts altogether is also
not recommended; maybe you should submit a kernel patch to make it
impossible to unlink it. You probably shouldn't remove /bin/ls
either, so better include that in the patch, too. And on and on. It
isn't possible for PostgreSQL or any other tool to protect itself
against every stupid configuration someone might create, and we
shouldn't try. root can bypass all permissions checks; that means
root can do really, incredibly dumb things. In the PostgreSQL world,
the database superuser can do similarly dumb things, like "DELETE FROM
pg_proc".
The question here is not whether it should be impossible to edit
/etc/hosts; it's whether it's ever a good idea to set up the
configuration you're describing. If there is a legitimate use-case
for that configuration, then we ought to support it, ideally without
adding a new GUC but perhaps doing so if there is no reasonable
alternative. But if the configuration that you're proposing is
something that no one should ever do in the first place, then it makes
no sense for us to spend time worrying about how to make it work. Tom
is arguing that it falls into the latter category. I am not sure that
he's right, but if you want to argue for this patch, you're argument
shouldn't be that more configuration knobs are better (which most
PostgreSQL project members, inculding me, do not believe, because it
means more code to maintain and frequently confuses users to no
benefit) but rather that this particular configuration option is
needed to support some sensible use case that can't be supported any
other way.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
I just migrate some services from one machine to another but database
stay there.
So, I think the most simple solution is to change “localhost” point to
the new one, so that I need no modification of client applications.
But found PG gave warnings.
On Fri, Oct 28, 2011 at 13:39, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
Show quoted text
Excerpts from Robert Young's message of vie oct 28 04:11:57 -0300 2011:
I am just wondering, why "localhost" entry in /etc/hosts is editable
and why 127.0.0.1 not fixed with loopback interface?
should you agree with that we should submit a patch to kernel to
resolve "localhost" to 127.0.0.1 statically need no entry in
/etc/hosts and loopback interface bind to 127.0.0.1 not changeable?
If your answer is NO.Maybe you can define localhost as an IPv6 address.
Why you give me this option to configure /etc/hosts or loopback
interface as well as deprive my option which hostname or IP for
statistics_collector to listen on?
Why operating system designed flexible and database system wrote in hard-coding?Are you solving a real problem here?
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Excerpts from Robert Young's message of vie oct 28 11:47:14 -0300 2011:
I just migrate some services from one machine to another but database
stay there.
So, I think the most simple solution is to change “localhost” point to
the new one, so that I need no modification of client applications.
But found PG gave warnings.
I'm surprised that your conclusion was that the path of least resistance
was submitting a patch to Postgres. Surely patching the apps would have
been a lot easier.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Don't be so surprised, because the app just as same as PG hard-coding
"localhost".
On Fri, Oct 28, 2011 at 14:54, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
Show quoted text
Excerpts from Robert Young's message of vie oct 28 11:47:14 -0300 2011:
I just migrate some services from one machine to another but database
stay there.
So, I think the most simple solution is to change “localhost” point to
the new one, so that I need no modification of client applications.
But found PG gave warnings.I'm surprised that your conclusion was that the path of least resistance
was submitting a patch to Postgres. Surely patching the apps would have
been a lot easier.--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera <alvherre@commandprompt.com> writes:
Excerpts from Robert Young's message of vie oct 28 11:47:14 -0300 2011:
I just migrate some services from one machine to another but database
stay there.
So, I think the most simple solution is to change “localhost” point to
the new one, so that I need no modification of client applications.
But found PG gave warnings.
I'm surprised that your conclusion was that the path of least resistance
was submitting a patch to Postgres. Surely patching the apps would have
been a lot easier.
The fundamental problem with that kluge (and yes, it's a kluge) is that
it supposes that you migrated EVERY local service to the other machine.
Which, obviously, you did not.
regards, tom lane
But...database and other services are not relevant.
And...client apps of course relevant to that services,but I have to
kluge to separate the increasing load.
And...client apps is just as same as PG hard-coding "localhost".
Show quoted text
On Fri, Oct 28, 2011 at 15:00, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alvaro Herrera <alvherre@commandprompt.com> writes:
Excerpts from Robert Young's message of vie oct 28 11:47:14 -0300 2011:
I just migrate some services from one machine to another but database
stay there.
So, I think the most simple solution is to change “localhost” point to
the new one, so that I need no modification of client applications.
But found PG gave warnings.I'm surprised that your conclusion was that the path of least resistance
was submitting a patch to Postgres. Surely patching the apps would have
been a lot easier.The fundamental problem with that kluge (and yes, it's a kluge) is that
it supposes that you migrated EVERY local service to the other machine.
Which, obviously, you did not.regards, tom lane
Which wrong?
1.I got no money to buy a good machine to run both the services and database.
2.I got no money to buy a good machine to run both the services and
client applications.
3.Client applications hard-coding "localhost".
4.PG hard-coding "localhost".
Show quoted text
On Fri, Oct 28, 2011 at 15:16, Robert Young <yayooo@gmail.com> wrote:
But...database and other services are not relevant.
And...client apps of course relevant to that services,but I have to
kluge to separate the increasing load.
And...client apps is just as same as PG hard-coding "localhost".On Fri, Oct 28, 2011 at 15:00, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alvaro Herrera <alvherre@commandprompt.com> writes:
Excerpts from Robert Young's message of vie oct 28 11:47:14 -0300 2011:
I just migrate some services from one machine to another but database
stay there.
So, I think the most simple solution is to change “localhost” point to
the new one, so that I need no modification of client applications.
But found PG gave warnings.I'm surprised that your conclusion was that the path of least resistance
was submitting a patch to Postgres. Surely patching the apps would have
been a lot easier.The fundamental problem with that kluge (and yes, it's a kluge) is that
it supposes that you migrated EVERY local service to the other machine.
Which, obviously, you did not.regards, tom lane
On 28.10.2011 18:40, Robert Young wrote:
Which wrong?
1.I got no money to buy a good machine to run both the services and database.
2.I got no money to buy a good machine to run both the services and
client applications.
3.Client applications hard-coding "localhost".
4.PG hard-coding "localhost".
#3. Fix the applications to not hard-code "localhost". The difference
between #3 and #4 is that PostgreSQL really genuinely always does mean
to connect to the local host, while #3 actually wants to connect to some
other host, but it was not made configurable.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
You got no knowledge about "client applications".
What you said is your assumption.
Without knowledge, you should consider them equivalent.
PG got no priority.
On Fri, Oct 28, 2011 at 16:03, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
Show quoted text
On 28.10.2011 18:40, Robert Young wrote:
Which wrong?
1.I got no money to buy a good machine to run both the services and
database.
2.I got no money to buy a good machine to run both the services and
client applications.
3.Client applications hard-coding "localhost".
4.PG hard-coding "localhost".#3. Fix the applications to not hard-code "localhost". The difference
between #3 and #4 is that PostgreSQL really genuinely always does mean to
connect to the local host, while #3 actually wants to connect to some other
host, but it was not made configurable.--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
