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

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?"