Re: [GENERAL] 60 Seconds to connected to Postgresql using ODBC or PGAdmin

2007-11-29 Thread Usama Dar
Or you can try using a simple packet sniffer, maybe ,ethereal , to see if
name resolution is going on, i had similar problems with MySQL name
resolution in the past and they generally went away after disabling its name
resolution and just use IPs

On Nov 29, 2007 1:23 PM, Shane Ambler <[EMAIL PROTECTED]> wrote:

> Richard Broersma Jr wrote:
> > --- On Wed, 11/28/07, Richard Huxton <[EMAIL PROTECTED]> wrote:
> >> Name lookups. Something is trying to look up a name,
> >> failing and it's
> >> timing out after 60 seconds.
> >
> > It seems the OP's connection string was set to localhost.  Would this
> still indicate a Name Loopup problem?
> >
>
> If there is no entry (or an incorrect one) in /etc/hosts for localhost -
> then yes - try to connect to 127.0.0.1 and see if that makes a difference.
>
> Also if it is set to do namelookup before referring to /etc/hosts it can
> have similar probs.
>
>
> --
>
> Shane Ambler
> [EMAIL PROTECTED]
>
> Get Sheeky @ http://Sheeky.Biz
>
> ---(end of broadcast)---
> TIP 1: if posting/reading through Usenet, please send an appropriate
>   subscribe-nomail command to [EMAIL PROTECTED] so that your
>   message can get through to the mailing list cleanly
>


Re: [GENERAL] 60 Seconds to connected to Postgresql using ODBC or PGAdmin

2007-11-29 Thread Shane Ambler

Richard Broersma Jr wrote:

--- On Wed, 11/28/07, Richard Huxton <[EMAIL PROTECTED]> wrote:

Name lookups. Something is trying to look up a name,
failing and it's 
timing out after 60 seconds.


It seems the OP's connection string was set to localhost.  Would this still 
indicate a Name Loopup problem?



If there is no entry (or an incorrect one) in /etc/hosts for localhost - 
then yes - try to connect to 127.0.0.1 and see if that makes a difference.


Also if it is set to do namelookup before referring to /etc/hosts it can 
have similar probs.



--

Shane Ambler
[EMAIL PROTECTED]

Get Sheeky @ http://Sheeky.Biz

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: [GENERAL] 60 Seconds to connected to Postgresql using ODBC or PGAdmin

2007-11-29 Thread Richard Huxton

Richard Broersma Jr wrote:

--- On Wed, 11/28/07, Richard Huxton <[EMAIL PROTECTED]> wrote:

Name lookups. Something is trying to look up a name, failing and
it's timing out after 60 seconds.


It seems the OP's connection string was set to localhost.  Would this
still indicate a Name Loopup problem?


That would make it unlikely.

The only other option that occurs to me would be some firewall type of 
package that's taking a long time to allow a connection. It would be an 
odd bit of security software that timed out and then *allowed* the 
connection to proceed.


Hmm - it looks like the wireshark network sniffer is available for 
Windows (http://www.wireshark.org/) - I'd be tempted to install that and 
connect to an external IP and see what packets go where. That will save 
a lot of head-scratching.


--
  Richard Huxton
  Archonet Ltd

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [GENERAL] 60 Seconds to connected to Postgresql using ODBC or PGAdmin

2007-11-29 Thread Peter

Richard Broersma Jr wrote:


It seems the OP's connection string was set to localhost.  Would this still 
indicate a Name Loopup problem?



Do you have some some firewall running ? Also is there a localhost entry 
in your hosts file(e.g /etc/hosts or C:/windows/system32/drivers/etc) ?


Peter


---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq


Re: [GENERAL] 60 Seconds to connected to Postgresql using ODBC or PGAdmin

2007-11-28 Thread Richard Broersma Jr
--- On Wed, 11/28/07, Richard Huxton <[EMAIL PROTECTED]> wrote:
> Name lookups. Something is trying to look up a name,
> failing and it's 
> timing out after 60 seconds.

It seems the OP's connection string was set to localhost.  Would this still 
indicate a Name Loopup problem?

Regards,
Richard

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org/


Re: [GENERAL] 60 Seconds to connected to Postgresql using ODBC or PGAdmin

2007-11-28 Thread Richard Huxton

Richard Broersma Jr wrote:

--- On Wed, 11/28/07, Finn Lassen <[EMAIL PROTECTED]> wrote:

Can anyone else comment on what problems could be causing these slow 
connections problems?



Meanwhile, I don't understand why it now takes exactly
60 seconds to connect to the database whether I use pgAdmin or my
connection string from within VB.


Name lookups. Something is trying to look up a name, failing and it's 
timing out after 60 seconds.


Could be DNS, or WINS (or whatever MS' current name resolution system is 
called). It could be either end of the connection too, if for example 
something on the server is logging the names of connecting clients.


Try a couple of name lookups (forward and reverse) from each end and see 
what happens.


--
  Richard Huxton
  Archonet Ltd

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq


[GENERAL] 60 Seconds to connected to Postgresql using ODBC or PGAdmin

2007-11-28 Thread Richard Broersma Jr
--- On Wed, 11/28/07, Finn Lassen <[EMAIL PROTECTED]> wrote:

Can anyone else comment on what problems could be causing these slow 
connections problems?


> Meanwhile, I don't understand why it now takes exactly
> 60 seconds to connect to the database whether I use pgAdmin or my
> connection string from within VB.

This is very odd.  Since you are having a problem with your connection time on 
both pgAdmin(which doesn't use ODBC to connect) and ODBC connects, I would 
assume that you must be having an issue that is non-odbc related.  

> I thought I had seen a comment about this somewhere, but can't find it 
> now. I've tried changing Connection Pooling in the OBDC Data Source 
> Administrator for the PostgreSQL ANSI driver, but doesn't have any 
> effect (or maybe just reloading the server configuration is not enough?

If this were an ODBC connection Issue, i would first make sure that all of ODBC 
logging was disabled on your client computer.  ODBC logging can really kill 
performance.

The windows ODBC tracing is found in the ODBC Datasource Administrator form -> 
tracing -> [Stop tracing now] & [Stop Visual Studio Analyzer now].

I guess it is impossible for postgresql ODBC logging to be taking place since 
you using a DNSless connection and have set any parameters to start the logging.

If all of the logging is already off, try turning turning on the Myloging and 
CommLogin by setting the appropriate setting in your DNS-less connection 
string.  If you post these logs, It will help others on the ODBC mailing list 
to trouble shoot where your problem is coming from.

Also on a side note, it is important to remember that many of the subscribers 
to the Postgresql mailing list are bombarded with countless emails on a daily 
basis.  

Do to the voluminous amount of emails, I am pretty sure that most subscribers 
pick and choose which emails they will read purely based on the interest 
generated by the email's subject heading.  

So to help encourage more subscribes to participate, it is important to make 
your subject headings very specific (to the point) and to make them as eye 
catching as possible.  You'll notice that I've alter your email subject a bit.  
Hopefully it will help get a few more people to join in on this thread.

There is nothing wrong with tackling a very difficult but general problem with 
postgresql by sending seperate emails with different subject heading the 
specifically address only the individual facets of the overall problem.  
Different people will probably respond to different facets of your overall 
problem.

Regarding the test case I sent to you, how many columns should I try to create 
in a table in order to reproduce the problem you where having with needing OIDs 
created in your tables?

Regards,
Richard Broersma Jr.

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match