Thread: 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.

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=3Dstrftime
"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:
> 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 i=
n 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 se=
nd
> bogus stat messages to the stats collector?
>
> --
> =C2=A0Heikki Linnakangas
> =C2=A0EnterpriseDB =C2=A0 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

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-co=
ding?

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?

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. =C2=A0Use 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.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0regards, 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)

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 =E2=80=9Clocalhost=E2=80=
=9D 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:
>
> 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?
>
> --
> =C3=81lvaro 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:
>
> 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 =E2=80=9Clocalhost=E2=
=80=9D 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. =C2=A0Surely patching the apps would =
have
> been a lot easier.
>
> --
> =C3=81lvaro 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".

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 =E2=80=9Clocalhost=E2=
=80=9D 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. =C2=A0Surely 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.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0regards, tom lane
>

Which wrong?
1.I got no money to buy a good machine to run both the services and databas=
e.
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".

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 =E2=80=9Clocalhost=
=E2=80=9D 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. =C2=A0Surely patching the apps woul=
d 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.
>>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0regards, 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:
> 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 oth=
er
> host, but it was not made configurable.
>
> --
> =C2=A0Heikki Linnakangas
> =C2=A0EnterpriseDB =C2=A0 http://www.enterprisedb.com
>

On 10/28/11 9:18 AM, Robert Young wrote:
> You got no knowledge about "client applications".
> What you said is your assumption.
> Without knowledge, you should consider them equivalent.
> PG got no priority.


1) your applications are assuming the database is running on the same
server.


2) postgres is assuming postgres is running on the same server


which of these two statements makes more sense?


--
john r pierce                            N 37, W 122
santa cruz ca                         mid-left coast

Robert Young <yayooo@gmail.com> writes:
> You got no knowledge about "client applications".
> What you said is your assumption.
> Without knowledge, you should consider them equivalent.
> PG got no priority.

Look, we will explain this once more.  Postgres is entitled to assume
that "localhost" means the local machine; there are Internet standards
saying so.  On the other hand, client applications that assume the
database server is on the same machine they are on are definitely
broken, and need to be fixed.

            regards, tom lane

It is client applications and services,NOT client applications and database.
It just term's (client applications, services) misleading.
To the system view,
You should definitely known they are relationship between process and proce=
ss.
Or I could still say some postgres process provide service,and some
postgres process is client.
PG process are just another couple of client and service.
Why my client applications could not get so closer relationship with
services,just like pg's client process and service's process ?

Still,You got no knowledge about "client applications and services".
What you said is your assumption.
Without knowledge, you should consider them equivalent.
PG got no priority.

On Fri, Oct 28, 2011 at 16:35, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Young <yayooo@gmail.com> writes:
>> You got no knowledge about "client applications".
>> What you said is your assumption.
>> Without knowledge, you should consider them equivalent.
>> PG got no priority.
>
> Look, we will explain this once more. =C2=A0Postgres is entitled to assume
> that "localhost" means the local machine; there are Internet standards
> saying so. =C2=A0On the other hand, client applications that assume the
> database server is on the same machine they are on are definitely
> broken, and need to be fixed.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0regards, tom lane
>

On Fri, Oct 28, 2011 at 15:40, Robert Young <yayooo@gmail.com> wrote:
> Which wrong?
> 1.I got no money to buy a good machine to run both the services and datab=
ase.
> 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".

Since They are equivalent,the answer is obvious:
Both #3 and #4 are wrong.

I admit, it is broken configuration.
But I said, broken configuration is just better than hard-coding.
Operating system designed flexible, give me the option to solve this
problem in broken configuration way.
Why database system wrote in hard-coding?

I admit, it is rare circumstance.
But I said, hard-coding is almost always right, NOT always right.
Just do the right thing is our rigorous attitude of work.

Database should be functional without underlying hostname or DNS facility.
So, I propose this patch to be applied.

On Fri, Oct 28, 2011 at 17:12, Robert Young <yayooo@gmail.com> wrote:
> It is client applications and services,NOT client applications and databa=
se.
> It just term's (client applications, services) misleading.
> To the system view,
> You should definitely known they are relationship between process and pro=
cess.
> Or I could still say some postgres process provide service,and some
> postgres process is client.
> PG process are just another couple of client and service.
> Why my client applications could not get so closer relationship with
> services,just like pg's client process and service's process ?
>
> Still,You got no knowledge about "client applications and services".
> What you said is your assumption.
> Without knowledge, you should consider them equivalent.
> PG got no priority.
>
> On Fri, Oct 28, 2011 at 16:35, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Robert Young <yayooo@gmail.com> writes:
>>> You got no knowledge about "client applications".
>>> What you said is your assumption.
>>> Without knowledge, you should consider them equivalent.
>>> PG got no priority.
>>
>> Look, we will explain this once more. =C2=A0Postgres is entitled to assu=
me
>> that "localhost" means the local machine; there are Internet standards
>> saying so. =C2=A0On the other hand, client applications that assume the
>> database server is on the same machine they are on are definitely
>> broken, and need to be fixed.
>>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0regards, tom lane
>>
>

On 11/01/11 1:04 AM, Robert Young wrote:
>> 3.Client applications hard-coding "localhost".
>> >  4.PG hard-coding "localhost".
> Since They are equivalent,the answer is obvious:
> Both #3 and #4 are wrong.

as Tom Lane already said, and I'll quote again..

> Look, we will explain this once more.  Postgres is entitled to assume
> that "localhost" means the local machine; there are Internet standards
> saying so.  On the other hand, client applications that assume the
> database server is on the same machine they are on are definitely
> broken, and need to be fixed.

anyways, this is NOT a postgresql bug, so this is the wrong list for
this discussion.



--
john r pierce                            N 37, W 122
santa cruz ca                         mid-left coast

You quoted Tom Lane.
But I already replied him as following,
So I quote mine again:

> On Fri, Oct 28, 2011 at 17:12, Robert Young <yayooo@gmail.com> wrote:
>> It is client applications and services,NOT client applications and database.
>> It just term's (client applications, services) misleading.
>> To the system view,
>> You should definitely known they are relationship between process and process.
>> Or I could still say some postgres process provide service,and some
>> postgres process is client.
>> PG process are just another couple of client and service.
>> Why my client applications could not get so closer relationship with
>> services,just like pg's client process and service's process ?
>>
>> Still,You got no knowledge about "client applications and services".
>> What you said is your assumption.
>> Without knowledge, you should consider them equivalent.
>> PG got no priority.
>>

Would you like to answer my puzzle:
Why my client applications could not get so closer relationship with
services,just like pg's client process and service's process ?
Do you have new opinion about my reply to Tom Lane?

On Tue, Nov 1, 2011 at 08:04, Robert Young <yayooo@gmail.com> wrote:
> On Fri, Oct 28, 2011 at 15:40, Robert Young <yayooo@gmail.com> 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".
>
> Since They are equivalent,the answer is obvious:
> Both #3 and #4 are wrong.
>
> I admit, it is broken configuration.
> But I said, broken configuration is just better than hard-coding.
> Operating system designed flexible, give me the option to solve this
> problem in broken configuration way.
> Why database system wrote in hard-coding?
>
> I admit, it is rare circumstance.
> But I said, hard-coding is almost always right, NOT always right.
> Just do the right thing is our rigorous attitude of work.
>
> Database should be functional without underlying hostname or DNS facility.
> So, I propose this patch to be applied.
>

>> On Fri, Oct 28, 2011 at 16:35, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Robert Young <yayooo@gmail.com> writes:
>>>> You got no knowledge about "client applications".
>>>> What you said is your assumption.
>>>> Without knowledge, you should consider them equivalent.
>>>> PG got no priority.
>>>
>>> Look, we will explain this once more.  Postgres is entitled to assume
>>> that "localhost" means the local machine; there are Internet standards
>>> saying so.  On the other hand, client applications that assume the
>>> database server is on the same machine they are on are definitely
>>> broken, and need to be fixed.
>>>
>>>                        regards, tom lane
>>>
>>
>

Andres Freund 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.

Do we throw at least a log message warning if localhost isn't resolved?
If not, we should.  (I don't want to break my OS to test this.)

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

Yes,PG told me about this:

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

On Wed, Nov 9, 2011 at 15:06, Bruce Momjian <bruce@momjian.us> wrote:
> Andres Freund 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 har=
sh but
>> that seems like it would end in heaps of workarounds.
>
> Do we throw at least a log message warning if localhost isn't resolved?
> If not, we should. =C2=A0(I don't want to break my OS to test this.)
>
> --
> =C2=A0Bruce Momjian =C2=A0<bruce@momjian.us> =C2=A0 =C2=A0 =C2=A0 =C2=A0h=
ttp://momjian.us
> =C2=A0EnterpriseDB =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://enterprisedb.com
>
> =C2=A0+ It's impossible for everything to be true. +
>

Robert Young wrote:
> Yes,PG told me about this:
>
> 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

Well, that's about as good as we can reasonably do.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

Sure! It give the right information to solve the problem.
But as I said:
On Fri, Oct 28, 2011 at 07:11, Robert Young <yayooo@gmail.com> wrote:
> 2.hard-coding is NOT configurable, that is the problem must be aided
> from OUTSIDE of the system to workaround.
>

On Wed, Nov 9, 2011 at 16:48, Bruce Momjian <bruce@momjian.us> wrote:
> Robert Young wrote:
>> Yes,PG told me about this:
>>
>> LOG: =C2=A0could not resolve "localhost": no address associated with name
>> LOG: =C2=A0disabling statistics collector for lack of working socket
>> WARNING: =C2=A0autovacuum not started because of misconfiguration
>> HINT: =C2=A0Enable the "track_counts" option.
>> LOG: =C2=A0database system was shut down at 2011-10-27 09:43:18 GMT
>> LOG: =C2=A0database system is ready to accept connections
>
> Well, that's about as good as we can reasonably do.
>
> --
> =C2=A0Bruce Momjian =C2=A0<bruce@momjian.us> =C2=A0 =C2=A0 =C2=A0 =C2=A0h=
ttp://momjian.us
> =C2=A0EnterpriseDB =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://enterprisedb.com
>
> =C2=A0+ It's impossible for everything to be true. +
>

Sure! It give the right information to workaround the problem.
But as I said:
On Fri, Oct 28, 2011 at 07:11, Robert Young <yayooo@gmail.com> wrote:
> 2.hard-coding is NOT configurable, that is the problem must be aided
> from OUTSIDE of the system to workaround.
>
And
On Tue, Nov 1, 2011 at 08:04, Robert Young <yayooo@gmail.com> wrote:
> Database should be functional without underlying hostname or DNS facility.
>

On Wed, Nov 9, 2011 at 16:48, Bruce Momjian <bruce@momjian.us> wrote:
> Robert Young wrote:
>> Yes,PG told me about this:
>>
>> LOG: =C2=A0could not resolve "localhost": no address associated with name
>> LOG: =C2=A0disabling statistics collector for lack of working socket
>> WARNING: =C2=A0autovacuum not started because of misconfiguration
>> HINT: =C2=A0Enable the "track_counts" option.
>> LOG: =C2=A0database system was shut down at 2011-10-27 09:43:18 GMT
>> LOG: =C2=A0database system is ready to accept connections
>
> Well, that's about as good as we can reasonably do.
>
> --
> =C2=A0Bruce Momjian =C2=A0<bruce@momjian.us> =C2=A0 =C2=A0 =C2=A0 =C2=A0h=
ttp://momjian.us
> =C2=A0EnterpriseDB =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://enterprisedb.com
>
> =C2=A0+ It's impossible for everything to be true. +
>

On 10/11/11 02:24, Robert Young wrote:
> Sure! It give the right information to workaround the problem.
> But as I said:
> On Fri, Oct 28, 2011 at 07:11, Robert Young <yayooo@gmail.com> wrote:
>> 2.hard-coding is NOT configurable, that is the problem must be aided
>> from OUTSIDE of the system to workaround.
>>
> And
> On Tue, Nov 1, 2011 at 08:04, Robert Young <yayooo@gmail.com> wrote:
>> Database should be functional without underlying hostname or DNS facility.

Why?

Should it also be functional without sockets?

How about without a file system?

Without an OS?


PostgreSQL is an application running on an OS, and expects to be able to
use the basic services of that OS. Those services include local DNS
resolution of local host names. Every OS since Windows 3.1.1, Mac OS 7,
and early BSD UNIXes has provided local DNS resolution and loopback
sockets. Why should PostgreSQL accomodate the lack of them? If it
should, where does it stop accomodating broken and cut-down OSes?

If you want an embedded database for an extremely cut down OS,
PostgreSQL isn't particularly suitable for a lot of reasons. For any
other use case there's no reason to expect local DNS resolution to be
broken.

--
Craig Ringer

The basic philosophy of system design is isolation.
One system component's crash should better not interfere others.
System should restrict destruction to minimum.

1.If the underling provide hostname or DNS facility, OK! It is better!
PG should take the benefit of it.
2.If the underling lack of hostname or DNS facility, Anyway, PG should
be founctional without it.
#1 and #2 are NOT conflict.

You further deduced conclusion is untenable.
Then ... I answer you further deduce.
Q1: Should it also be functional without sockets?
A1: If the system lack of IP sockets, PG should be founctional with
unix-domain sockets. ...

Q2: How about without a file system?
A2: We suppose PG support raw devices, if file system crashed, raw
devices part of PG should remain founctional.

Q3: Without an OS?
A3: Think about vmware, If my vmware workstation crashed, I could
transfer my guest machine to vmware ESX which runs on bare metal.

The conclusion is obvious:
If underling lack of hostname or DNS facility, PG should be
founctional with IP address.
Still:
On Tue, Nov 1, 2011 at 08:04, Robert Young <yayooo@gmail.com> wrote:
> Database should be functional without underlying hostname or DNS facility.


On Thu, Nov 10, 2011 at 02:17, Craig Ringer <ringerc@ringerc.id.au> wrote:
> On 10/11/11 02:24, Robert Young wrote:
>> Sure! It give the right information to workaround the problem.
>> But as I said:
>> On Fri, Oct 28, 2011 at 07:11, Robert Young <yayooo@gmail.com> wrote:
>>> 2.hard-coding is NOT configurable, that is the problem must be aided
>>> from OUTSIDE of the system to workaround.
>>>
>> And
>> On Tue, Nov 1, 2011 at 08:04, Robert Young <yayooo@gmail.com> wrote:
>>> Database should be functional without underlying hostname or DNS facility.
>
> Why?
>
> Should it also be functional without sockets?
>
> How about without a file system?
>
> Without an OS?
>
>
> PostgreSQL is an application running on an OS, and expects to be able to
> use the basic services of that OS. Those services include local DNS
> resolution of local host names. Every OS since Windows 3.1.1, Mac OS 7,
> and early BSD UNIXes has provided local DNS resolution and loopback
> sockets. Why should PostgreSQL accomodate the lack of them? If it
> should, where does it stop accomodating broken and cut-down OSes?
>
> If you want an embedded database for an extremely cut down OS,
> PostgreSQL isn't particularly suitable for a lot of reasons. For any
> other use case there's no reason to expect local DNS resolution to be
> broken.
>
> --
> Craig Ringer
>
>

On Thu, Nov 10, 2011 at 12:09 AM, Robert Young <yayooo@gmail.com> wrote:
> The basic philosophy of system design is isolation.
> One system component's crash should better not interfere others.
> System should restrict destruction to minimum.

The "minimum" may not be able to be lowered to zero.

Such a lowering may be:
a) Completely impossible, or
b) So challenging that it's reasonable to treat it as undesirable to
go that far.

> 1.If the underling provide hostname or DNS facility, OK! It is better!
> PG should take the benefit of it.
> 2.If the underling lack of hostname or DNS facility, Anyway, PG should
> be founctional without it.
> #1 and #2 are NOT conflict.

If we ignore the use of UDS, Postgres essentially requires having a
properly functioning TCP/IP implementation.

In order to be able to cope with completely deranged TCP/IP
configuration would require at the very least some planning to know
how to cope with the erroneous conditions, and perhaps would imply a
need to implement a functioning TCP/IP stack.

I'm actually reasonably comfortable with requiring that the system's
TCP/IP implementation is not SO broken that it can't cope with
localhost, and I don't think I'm alone in this.  Apparently, a bunch
of people don't agree with your metric in this regard.

> Q2: How about without a file system?
> A2: We suppose PG support raw devices, if file system crashed, raw
> devices part of PG should remain founctional.
>
> Q3: Without an OS?
> A3: Think about vmware, If my vmware workstation crashed, I could
> transfer my guest machine to vmware ESX which runs on bare metal.

Both Q2 and Q3 head well into the realm where your assumption
essentially requires that Postgres implement its own operating system
from scratch.  There is increasing agreement that:
a) Such a requirement would be a bad idea, and
b) We have actually had benefit from NOT requiring such.

The big name DBMSes that *do* implement their own filesystems turn out
to be troublesome to run in emulated environments like VMWare.  In
contrast, running Postgres atop Linux atop VMWare works perfectly
well.

Further, since we *don't* require bare metal raw disk access:
a) We work fine on Linux, and all BSD flavors, and even Windows,
without some heinous burden of an API to emulate raw access atop each
one of those
b) We get full benefit of clever filesystem improvements as with
BTRFS, ZFS, and such, which would be effectively impossible if we were
doing "RawFS".
c) Let me repeat a) in a different way.  We don't need to have our own
filesystem implementation, and hence our own set of filesystem
hackers, as well as a further set of hackers responsible for building
a portability layer so that the custom filesystem would work on all
the operating systems we expect to run on.

All these things (expecting to have functioning TCP/IP, filesystem,
and operating system) are similar.  By expecting these services from
the operating system, we don't need to duplicate that functionality
into Postgres.  And improvements made to Linux or Solaris or
DragonflyBSD are things we can take advantage of, often simply by
installing Postgres on a newer OS version; we don't need to write a
single line of code.  I think you'll find that a large portion of our
users and developers find that preferable to your metrics/desires.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"

On 10.11.2011 07:09, Robert Young wrote:
> 2.If the underling lack of hostname or DNS facility, Anyway, PG should
> be founctional without it.

It is. It's just the stats collector that won't work, and autovacuum
which depends on a working stats collector. Otherwise the system is
functional.

--
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

Are you answering to me?
Oh,
I don't want you implement TCP/IP.
I don't want you implement file system.
I don't want you implement OS.
Really!
In fact, about these, I think exactly the same way.

There are two parts:

1.Feature that PG will NOT support (raw devices,bare metal,So I said "suppo=
se").
Both of us agree with should not implement them.
It is Craig Ringer's deduce, All of us don't agree with that. So, I
don't agree with my statements which basis on Craig Ringer's deduce
too.
You need not argue with me.
You wrote too much about it.

2.Feature that PG stated supported.
Controversy is here!
PG support TCP/IP sockets and UNIX-domain sockets.
So I said:
On Thu, Nov 10, 2011 at 05:09, Robert Young <yayooo@gmail.com> wrote:
> Q1: Should it also be functional without sockets?
> A1: If the system lack of IP sockets, PG should be founctional with
> unix-domain sockets. ...
I told you to transfer to UNIX-domain sockets.
I did NOT told you to implement TCP/IP.
I am expecting UNIX-domain sockets is OK.
Did you read that?

I said, "features that PG stated supported" should be functional.
PG support IP address, so, I am expecting PG functional without
underlying hostname or DNS facility.
Do you read that?

On Thu, Nov 10, 2011 at 05:46, Christopher Browne <cbbrowne@gmail.com> wrot=
e:
> On Thu, Nov 10, 2011 at 12:09 AM, Robert Young <yayooo@gmail.com> wrote:
>> The basic philosophy of system design is isolation.
>> One system component's crash should better not interfere others.
>> System should restrict destruction to minimum.
>
> The "minimum" may not be able to be lowered to zero.
>
> Such a lowering may be:
> a) Completely impossible, or
> b) So challenging that it's reasonable to treat it as undesirable to
> go that far.
>
>> 1.If the underling provide hostname or DNS facility, OK! It is better!
>> PG should take the benefit of it.
>> 2.If the underling lack of hostname or DNS facility, Anyway, PG should
>> be founctional without it.
>> #1 and #2 are NOT conflict.
>
> If we ignore the use of UDS, Postgres essentially requires having a
> properly functioning TCP/IP implementation.
>
> In order to be able to cope with completely deranged TCP/IP
> configuration would require at the very least some planning to know
> how to cope with the erroneous conditions, and perhaps would imply a
> need to implement a functioning TCP/IP stack.
>
> I'm actually reasonably comfortable with requiring that the system's
> TCP/IP implementation is not SO broken that it can't cope with
> localhost, and I don't think I'm alone in this. =C2=A0Apparently, a bunch
> of people don't agree with your metric in this regard.
>
>> Q2: How about without a file system?
>> A2: We suppose PG support raw devices, if file system crashed, raw
>> devices part of PG should remain founctional.
>>
>> Q3: Without an OS?
>> A3: Think about vmware, If my vmware workstation crashed, I could
>> transfer my guest machine to vmware ESX which runs on bare metal.
>
> Both Q2 and Q3 head well into the realm where your assumption
> essentially requires that Postgres implement its own operating system
> from scratch. =C2=A0There is increasing agreement that:
> a) Such a requirement would be a bad idea, and
> b) We have actually had benefit from NOT requiring such.
>
> The big name DBMSes that *do* implement their own filesystems turn out
> to be troublesome to run in emulated environments like VMWare. =C2=A0In
> contrast, running Postgres atop Linux atop VMWare works perfectly
> well.
>
> Further, since we *don't* require bare metal raw disk access:
> a) We work fine on Linux, and all BSD flavors, and even Windows,
> without some heinous burden of an API to emulate raw access atop each
> one of those
> b) We get full benefit of clever filesystem improvements as with
> BTRFS, ZFS, and such, which would be effectively impossible if we were
> doing "RawFS".
> c) Let me repeat a) in a different way. =C2=A0We don't need to have our o=
wn
> filesystem implementation, and hence our own set of filesystem
> hackers, as well as a further set of hackers responsible for building
> a portability layer so that the custom filesystem would work on all
> the operating systems we expect to run on.
>
> All these things (expecting to have functioning TCP/IP, filesystem,
> and operating system) are similar. =C2=A0By expecting these services from
> the operating system, we don't need to duplicate that functionality
> into Postgres. =C2=A0And improvements made to Linux or Solaris or
> DragonflyBSD are things we can take advantage of, often simply by
> installing Postgres on a newer OS version; we don't need to write a
> single line of code. =C2=A0I think you'll find that a large portion of our
> users and developers find that preferable to your metrics/desires.
> --
> When confronted by a difficult problem, solve it by reducing it to the
> question, "How would the Lone Ranger handle this?"
>

Heikki Linnakangas schrieb:
> On 10.11.2011 07:09, Robert Young wrote:
>> 2.If the underling lack of hostname or DNS facility, Anyway, PG should
>> be founctional without it.
>
> It is. It's just the stats collector that won't work, and autovacuum
> which depends on a working stats collector. Otherwise the system is
> functional.

But it will get broken! Without the autovacuum (and a manual vacuum) a
PG installation could run into loss of (very) old data, because of the
transaction ID wraparound.

Lossing data is very bad, the solution provided by Robert is really
simple. I support Roberts approach.

Greetings from Germany,
Torsten
--
http://www.dddbl.de - ein Datenbank-Layer, der die Arbeit mit 8
verschiedenen Datenbanksystemen abstrahiert,
Queries von Applikationen trennt und automatisch die Query-Ergebnisse
auswerten kann.

On 11/09/11 11:46 PM, Torsten Zuehlsdorff wrote:
> Lossing data is very bad, the solution provided by Robert is really
> simple. I support Roberts approach.

you support changing localhost to be something other than 127.0.0.1 to
hack around a poorly designed application?!?   seriously?


--
john r pierce                            N 37, W 122
santa cruz ca                         mid-left coast

John R Pierce schrieb:
> On 11/09/11 11:46 PM, Torsten Zuehlsdorff wrote:
>> Lossing data is very bad, the solution provided by Robert is really
>> simple. I support Roberts approach.
>
> you support changing localhost to be something other than 127.0.0.1 to
> hack around a poorly designed application?!?   seriously?

No, i support that PG should be able to not lossing data because of an
easily catchable missconfiguration of the underlying system.

Greetings,
Torsten
--
http://www.dddbl.de - ein Datenbank-Layer, der die Arbeit mit 8
verschiedenen Datenbanksystemen abstrahiert,
Queries von Applikationen trennt und automatisch die Query-Ergebnisse
auswerten kann.

On 10.11.2011 11:26, Torsten Zuehlsdorff wrote:
> John R Pierce schrieb:
>> On 11/09/11 11:46 PM, Torsten Zuehlsdorff wrote:
>>> Lossing data is very bad, the solution provided by Robert is really
>>> simple. I support Roberts approach.
>>
>> you support changing localhost to be something other than 127.0.0.1 to
>> hack around a poorly designed application?!? seriously?
>
> No, i support that PG should be able to not lossing data because of an
> easily catchable missconfiguration of the underlying system.

You won't lose data. There are safeguards in place to print warnings in
the log when you approach transaction wrap-around, and after a certain
point the system will stop accepting new transactions, to prevent data loss.

If autovacuum is not working and you're not doing manual vacuums, you
will likely have an extremely bloted database anyway, before you reach
wrap-around.

--
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

The answer is simple.
You said, just the stats collector have some trouble.
Then I say, I just want to fix the stats collector.
You said, other things are OK.
Then I say, I never want to fix other things.

I just plead with you to fix the very thing that you admit not
functional properly.
The whole database is almost functional, we won't fix the whole.
Component of it get in trouble, we fix the component.
The whole is almost functional can be a reason that we should not fix
the nonfunctional component.

On Thu, Nov 10, 2011 at 06:36, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> On 10.11.2011 07:09, Robert Young wrote:
>>
>> 2.If the underling lack of hostname or DNS facility, Anyway, PG should
>> be functional without it.
>
> It is. It's just the stats collector that won't work, and autovacuum which
> depends on a working stats collector. Otherwise the system is functional.
>
> --
> =C2=A0Heikki Linnakangas
> =C2=A0EnterpriseDB =C2=A0 http://www.enterprisedb.com
>

The answer is simple.
You said, just the stats collector have some trouble.
Then I say, I just want to fix the stats collector.
You said, other things are OK.
Then I say, I never want to fix other things.

I just plead with you to fix the very thing that you admit not
functional properly.
The whole database is almost functional, we won't fix the whole.
Component of it get in trouble, we fix the component.
The whole is almost functional can NOT be a reason that we should not
fix the nonfunctional component.

On Thu, Nov 10, 2011 at 06:36, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> On 10.11.2011 07:09, Robert Young wrote:
>>
>> 2.If the underling lack of hostname or DNS facility, Anyway, PG should
>> be founctional without it.
>
> It is. It's just the stats collector that won't work, and autovacuum which
> depends on a working stats collector. Otherwise the system is functional.
>
> --
> =C2=A0Heikki Linnakangas
> =C2=A0EnterpriseDB =C2=A0 http://www.enterprisedb.com
>

Robert Young wrote:
> The answer is simple.
> You said, just the stats collector have some trouble.
> Then I say, I just want to fix the stats collector.
> You said, other things are OK.
> Then I say, I never want to fix other things.
>
> I just plead with you to fix the very thing that you admit not
> functional properly.
> The whole database is almost functional, we won't fix the whole.
> Component of it get in trouble, we fix the component.
> The whole is almost functional can NOT be a reason that we should not
> fix the nonfunctional component.

You are free to distribute your own version of Postgres that does
whatever you think is best.  Our community has given ample thought to
your ideas and has rejected them.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

Anyway...
Thanks to all of you for answering my puzzles, even though none of you
gave feasible answer ...

On Fri, Nov 11, 2011 at 00:42, Bruce Momjian <bruce@momjian.us> wrote:
> Robert Young wrote:
>> The answer is simple.
>> You said, just the stats collector have some trouble.
>> Then I say, I just want to fix the stats collector.
>> You said, other things are OK.
>> Then I say, I never want to fix other things.
>>
>> I just plead with you to fix the very thing that you admit not
>> functional properly.
>> The whole database is almost functional, we won't fix the whole.
>> Component of it get in trouble, we fix the component.
>> The whole is almost functional can NOT be a reason that we should not
>> fix the nonfunctional component.
>
> You are free to distribute your own version of Postgres that does
> whatever you think is best. =C2=A0Our community has given ample thought to
> your ideas and has rejected them.
>
> --
> =C2=A0Bruce Momjian =C2=A0<bruce@momjian.us> =C2=A0 =C2=A0 =C2=A0 =C2=A0h=
ttp://momjian.us
> =C2=A0EnterpriseDB =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://enterprisedb.com
>
> =C2=A0+ It's impossible for everything to be true. +
>

Heikki Linnakangas schrieb:

>>>> Lossing data is very bad, the solution provided by Robert is really
>>>> simple. I support Roberts approach.
>>>
>>> you support changing localhost to be something other than 127.0.0.1 to
>>> hack around a poorly designed application?!? seriously?
>>
>> No, i support that PG should be able to not lossing data because of an
>> easily catchable missconfiguration of the underlying system.
>
> You won't lose data. There are safeguards in place to print warnings in
> the log when you approach transaction wrap-around, and after a certain
> point the system will stop accepting new transactions, to prevent data
> loss.

The manual says that autovacuum protects againt loss of very old data:
http://www.postgresql.org/docs/9.1/static/routine-vacuuming.html

So either your statement is wrong or the manual. ;) If there is the
possibility to lose data just because of this kind of missconfiguration,
we should accept Roberts patch.

Greetings,
Torsten
--
http://www.dddbl.de - ein Datenbank-Layer, der die Arbeit mit 8
verschiedenen Datenbanksystemen abstrahiert,
Queries von Applikationen trennt und automatisch die Query-Ergebnisse
auswerten kann.

On 11/11/11 20:51, Torsten Zuehlsdorff wrote:
>
>
> So either your statement is wrong or the manual. ;) If there is the
> possibility to lose data just because of this kind of
> missconfiguration, we should accept Roberts patch.
>
> Greetings,
> Torsten

Robert's patch is based on a complete mis-assessment risk and
misunderstanding of sane network configuration. No-one can sensibly
support a position to redefine 'localhost' to mean what it should never
mean.

regards

Mark

Excerpts from Torsten Zuehlsdorff's message of vie nov 11 04:51:48 -0300 2011:
> Heikki Linnakangas schrieb:
> > You won't lose data. There are safeguards in place to print warnings in
> > the log when you approach transaction wrap-around, and after a certain
> > point the system will stop accepting new transactions, to prevent data
> > loss.
>
> The manual says that autovacuum protects againt loss of very old data:
> http://www.postgresql.org/docs/9.1/static/routine-vacuuming.html
>
> So either your statement is wrong or the manual. ;)

Heikki is correct.  The docs state, in the section that expands on the
single phrase talking about very old data being lost:

    If for some reason autovacuum fails to clear old XIDs from a table, the
    system will begin to emit warning messages like this when the database's oldest
    XIDs reach ten million transactions from the wraparound point:

    WARNING:  database "mydb" must be vacuumed within 177009986 transactions
    HINT:  To avoid a database shutdown, execute a database-wide VACUUM in "mydb".

    (A manual VACUUM should fix the problem, as suggested by the hint; but
    note that the VACUUM must be performed by a superuser, else it will fail to
    process system catalogs and thus not be able to advance the database's
    datfrozenxid.) If these warnings are ignored, the system will shut down and
    refuse to start any new transactions once there are fewer than 1 million
    transactions left until wraparound:

    ERROR:  database is not accepting commands to avoid wraparound data loss in database "mydb"
    HINT:  Stop the postmaster and use a standalone backend to VACUUM in "mydb".

    The 1-million-transaction safety margin exists to let the administrator
    recover without data loss, by manually executing the required VACUUM commands.
    However, since the system will not execute commands once it has gone into the
    safety shutdown mode, the only way to do this is to stop the server and use a
    single-user backend to execute VACUUM. The shutdown mode is not enforced by a
    single-user backend. See the postgres reference page for details about using a
    single-user backend.


So you don't actually lose data, but it's better not to get into that
situation in the first place.

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support