Re: Add statistics_collector_listen_addresses to fix hard-coding of "localhost"

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 "suppose").
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(at)gmail(dot)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(at)gmail(dot)com> wrote:
> On Thu, Nov 10, 2011 at 12:09 AM, Robert Young <yayooo(at)gmail(dot)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?"
>