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
On 28/10/11 08:53, Tom Lane wrote:
Gavin Flower writes:
Actually, a minute is not always 60 seconds, as you can legally have 62
seconds in a minute!
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
On Thu, Oct 27, 2011 at 6:15 PM, Tom Lane wrote:
> Noah Misch writes:
>> Let's look at the behavior of DDL-exposed access constraints for precedent.
>> We
>> currently have three paradigms for applying access control to superusers:
>
>> 1. Settings that affect superusers and regular users ident
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.
On Fri, Oct 28, 2011 at 3:11 AM, Robert Young 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 n
On Thu, Oct 27, 2011 at 7:02 PM, goudvis wrote:
> A few updates from my side:
> Kevin helped me find two bugs in my test suite. The first: the test suite
> had a syntax error in setting the isolation level, which resulted in not
> setting an isolation level at all. Secondly, I made a mistake in th
Robert Haas writes:
> On Thu, Oct 27, 2011 at 6:15 PM, Tom Lane wrote:
>> Noah Misch writes:
>>> I think we should merge #3 into #2; nothing about the REPLICATION setting
>>> justifies a distinct paradigm.
>> Yeah, there's much to be said for that. I thought the notion of a
>> privilege that s
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
wr
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 applicat
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
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 t
Alvaro Herrera 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 m
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 wrote:
> Alvaro Herrera writes:
On Fri, Oct 28, 2011 at 09:32:30AM -0400, Robert Haas wrote:
> On Thu, Oct 27, 2011 at 6:15 PM, Tom Lane wrote:
> > Noah Misch writes:
> >> Let's look at the behavior of DDL-exposed access constraints for
> >> precedent. ?We
> >> currently have three paradigms for applying access control to supe
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".
On Fri, Oct 28, 2011 at 15:16, Robert You
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".
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
wrote:
> On 28.10.2011 18:40, Robert Young wrote:
>>
>> Which wrong?
>> 1.I got no mone
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
Robert Young 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 machi
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 s
Robert Haas wrote:
>
> I would be curious to see (updated, corrected) results on older versions.
>
If I am correct, Kevin Grittner is writing a review of the code and the
testing methods. I think it would be wise to wait for the outcome of this.
Afterwards, I could post the code and the executi
goudvis wrote:
> Robert Haas wrote:
>>
>> I would be curious to see (updated, corrected) results on older
>> versions.
>
> If I am correct, Kevin Grittner is writing a review of the code
> and the testing methods. I think it would be wise to wait for the
> outcome of this. Afterwards, I could po
Composite types are converted to and from Perl hashes since commit
REL9_1_ALPHA4~146 (Convert Postgres arrays to Perl arrays on PL/perl input
arguments; 2011-02-17), but are not stringified as claimed by the commit
message and release notes (unless nested in an array).
To illustrate:
CREATE TYPE
On Fri, Oct 28, 2011 at 16:42, Mischa POSLAWSKY wrote:
> Composite types are converted to and from Perl hashes since commit
> REL9_1_ALPHA4~146 (Convert Postgres arrays to Perl arrays on PL/perl input
> arguments; 2011-02-17), but are not stringified as claimed by the commit
> message and release
23 matches
Mail list logo
