Hi,
I have a very weird problem related to establishing remote connections
to PostgreSQL server and hopefully someone can give me some hints how
can I debug this.
The essence is that establishing remote connection takes anywhere from
10 to 30 seconds. Once connected, the queries are fast - it's j
=?UTF-8?Q?Mindaugas_=C5=BDak=C5=A1auskas?= writes:
> I have a very weird problem related to establishing remote connections
> to PostgreSQL server and hopefully someone can give me some hints how
> can I debug this.
> The essence is that establishing remote connection takes anywhere from
> 10 to
Hi Tom,
Thanks for your reply.
> Perhaps the problem is related to authentication - what auth mode
> are you using, and can you experiment with some other ones?
Excerpt from my pg_hba.conf
local all all trust
hostall
=?UTF-8?Q?Mindaugas_=C5=BDak=C5=A1auskas?= writes:
>> What about "psql -h localhost", ie physically local connection but
>> via TCP not unix socket?
> user@dbserver> psql -h 127.0.0.1 -p5432 -U user -W db
> This works fast. But
> user@dbserver> psql -h -p5432 -U user -W db
> (where is the mu
Hello,
What i have to do to remove the following post:
http://archives.postgresql.org/pgsql-admin/2009-09/msg00141.php
Thnks,
Rafael
On Tue, Jan 17, 2012 at 3:41 PM, Tom Lane wrote:
> Hm. AFAIR postgres doesn't know anything particular about multipath
> interfaces --- it just listens where you tell it to.
I was thinking the same, but PostgreSQL is the "first line to contact"
and I somehow need to obtain a proof that this is
Mindaugas Žakšauskas wrote:
> The essence is that establishing remote connection takes anywhere
> from 10 to 30 seconds. Once connected, the queries are fast
The only time I've seen something similar, there was no reverse DNS
entry to go from IP address to host name. Adding that corrected the
"Kevin Grittner" writes:
> Mindaugas ´ak¨auskas wrote:
>> The essence is that establishing remote connection takes anywhere
>> from 10 to 30 seconds. Once connected, the queries are fast
> The only time I've seen something similar, there was no reverse DNS
> entry to go from IP address to host n
Tom Lane wrote:
> "Kevin Grittner" writes:
>> Mindaugas *ak*auskas wrote:
>>> The essence is that establishing remote connection takes
>>> anywhere from 10 to 30 seconds. Once connected, the queries are
>>> fast
>
>> The only time I've seen something similar, there was no reverse
>> DNS entry t
Rafael Domiciano wrote:
> What i have to do to remove the following post:
>
> http://archives.postgresql.org/pgsql-admin/2009-09/msg00141.php
I'm not sure it is possible to have a public post removed from the
archives; but if it is, pgsql-admin would probably not be read by
the folks with rig
"Kevin Grittner" writes:
> Actually, where I've seen this sort of problem, it was the client
> code which was doing the unnecessary reverse DNS lookup. What
> controls this in psql?
psql? AFAIR psql itself doesn't do any such thing.
It's possible that certain libraries such as SSL or Kerberos
On Tue, 17 Jan 2012 11:41:13 -0600
"Kevin Grittner" wrote:
> I'm not sure it is possible to have a public post removed from the
> archives;
No, its not. You cannot purge a post from all mirrors etc. Its a
mailing list, not a centralist forum or newsgroup.
Cheers,
Frank
--
Frank Lanitz
pgp
On Tue, Jan 17, 2012 at 12:30 PM, Frank Lanitz wrote:
> On Tue, 17 Jan 2012 11:41:13 -0600
> "Kevin Grittner" wrote:
>
>> I'm not sure it is possible to have a public post removed from the
>> archives;
>
> No, its not. You cannot purge a post from all mirrors etc. Its a
> mailing list, not a cent
On Tue, Jan 17, 2012 at 7:23 PM, Tom Lane wrote:
> <..> Mindaugas, are you using SSL,
> and if so can you turn it off and see whether things change?
> (It should be safe to do so at least on the "localhost" connection,
> even if you feel your network is insecure.)
No, I am not using SSL; it is e
Hi,
if you try to connect with pssql over your IP and it works slow, it is
possible that you have problem with reverse dns lookup. To check, try to
run nslookup tool, and enter your IP address (on the same machine) - if
it is problem with dns, it will resolve it slow as well..
Also, try to chec
2012/1/17 Mindaugas Žakšauskas
> On Tue, Jan 17, 2012 at 7:23 PM, Tom Lane wrote:
> > <..> Mindaugas, are you using SSL,
> > and if so can you turn it off and see whether things change?
> > (It should be safe to do so at least on the "localhost" connection,
> > even if you feel your network is
Thanks for your views.
(1) Will try out emptying synchronous_standby_names on replica failures
and verify if the transactions proceeds thru.
(2) We are not comfortable moving to PGPool just for automatic failback
mode on hot-standby failure. Any suggestions on how to build this
failback mech
I finally had time to test this further on a variety of systems, and was
unable to reproduce on any non-Windows platform. The dump even works fine
on Windows XP; just not Windows 7.
This prompted me to do a little more research, and this time I found this
thread from Sept. 2011:
http://postgresq
On Mon, 16 Jan 2012 23:24:41 +0300, David M. Gullever wrote:
> Question - user postgres
>
> If the admin is creating various "postgresql" users to work on different
> databases - is it advisable to create these as "LINUX" users so that
> they have a home directory for saving their scripts - and w
Hi,
if you try to connect with pssql over your IP and it works slow, it is
possible that you have problem with reverse dns lookup. To check, try to
run nslookup tool, and enter your IP address (on the same machine) - if
it is problem with dns, it will resolve it slow as well..
Also, try to check
Walter Hurry wrote:
> User postgres does *not* need to log in to Unix/Linux directly,
> and therefore should *not* be assigned a password.
I totally agree. In fact, for most use-cases, you don't need or
want the users of the database to be able to log on to the box with
the database. Let the
On Wed, Jan 18, 2012 at 6:37 AM, Manoj Govindassamy
wrote:
> (2) We are not comfortable moving to PGPool just for automatic failback mode
> on hot-standby failure.
Hmm.. my reply might be misleading. What I meant was to use pgpool-II
as a clusterware for PostgreSQL built-in replication, not as a
I am aware of pgpool-II and its features. Just that my requirements are
little different. I have a System (PG runs on it) which already has
Failover mechanism to another System and I want PG to be part of this
cluster and not clustered on its own. Mean, PG has to be running in
Master system an
On Wed, Jan 18, 2012 at 10:54 AM, Manoj Govindassamy
wrote:
> I am aware of pgpool-II and its features. Just that my requirements are
> little different. I have a System (PG runs on it) which already has
> Failover mechanism to another System and I want PG to be part of this
> cluster and not clu
> I am aware of pgpool-II and its features. Just that my requirements
> are little different. I have a System (PG runs on it) which already
> has Failover mechanism to another System and I want PG to be part of
> this cluster and not clustered on its own. Mean, PG has to be running
> in Master sys
25 matches
Mail list logo
