Re: [pgadmin-hackers] Pgadmin III connection error

2005-09-16 Thread Devrim Gunduz


Hi,

At last I was removed from all blacklists :-D

(Reply below)

On Sun, 11 Sep 2005, Raphaël Enrici wrote:


I'm running the Postgres 7.4.2 and the Pgadmin3 1.2.0 Beta 1 (5Nov 2004)
on a Fedora Core 2 Kernel 2.6.5.


Ok, I've CCed Devrim who is responsible of the fedora port



The PGadmin3 connection to a remote machine (in other city) occurs OK.

When I try to connect to a database (filling with 127.0.0.1 the field
Address in the Add server PGadmin form) in the same machine in that
PGadmin runs too, I receive the message :

src/common/string.cpp(1060) : assert nLen != (size_t) - 1


It reminds me an old bug corrected in 1.2.2 and may be in 1.2.0 final
which occured in particular locales when receiving an error message from
the backend.


We don't have packages for Red Hat 7.3 (he is using that). I believe it is 
time for OS upgrade :-) That might also be the reason , due to Wx 
problems.


Regards,
--
Devrim GUNDUZ
Kivi Bilişim Teknolojileri
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
  http://www.gunduz.org
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [pgadmin-hackers] Pgadmin III connection error

2005-09-11 Thread Raphaël Enrici
Olimpio wrote:
 [EMAIL PROTECTED] wrote:
 
 
Message d'origine
 


Date: Thu, 08 Sep 2005 15:18:20 -0300
De: Olimpio [EMAIL PROTECTED]
A: [EMAIL PROTECTED]
Sujet: Pgadmin III connection error

Raphael,
   


Hi,

please post such question to pgadmin-support or pgadmin-hackers, there is 
more chance for you to get a rapid answer and others may benefit from such 
experience :).
I'm trying to connect to a local database with pgadmin and receipt an 
error message : src/common/string.cpp(1060) : assert nLen != (size_t) - 1

Can you give more details please? Which version of pgAdmin are you using? 
What OS (I suppose Debian GNU/Linux as you asked me first)? What exact 
release of the OS?
Can you configure pgAdmin to log debug information and provide the log file 
(beware to clean it from personnal informations if you care)?

The database is running in the same machine I'm using the pgadmin III.
   
So, it may be the pgAdmin 1.3.x release I made during summer with a 
connection to a local unix socket or are you trying to connect to 127.0.0.1 
in tcp mode?


Can you help me ?

I bet everybody here would be glad to help :)

Waiting for your updates concerning this.

 
 Raphaël,
 
 I'd would like to thank for the help.

NP, but stay on the list please...


 I'm running the Postgres 7.4.2 and the Pgadmin3 1.2.0 Beta 1 (5Nov 2004) 
 on a Fedora Core 2 Kernel 2.6.5.

Ok, I've CCed Devrim who is responsible of the fedora port


 The PGadmin3 connection to a remote machine (in other city) occurs OK.
 
 When I try to connect to a database (filling with 127.0.0.1 the field 
 Address in the Add server PGadmin form) in the same machine in that 
 PGadmin runs too, I receive the message :
 
 src/common/string.cpp(1060) : assert nLen != (size_t) - 1

It reminds me an old bug corrected in 1.2.2 and may be in 1.2.0 final
which occured in particular locales when receiving an error message from
the backend.


 Does this have any relation with the problem below ?

I think so (some bet follows)


 I have another problem and I'd appreciate if you can tell me how to solve.
 
 At the shell command line I type : psql -h 200.101.18.22 -d MDI -U MDI
 
 I connect to the database int the remote location (another city) OK.
 
 But if I try to connect to a database that is local instance of a 
 database (I dumped the remote database with pg_dump and brought to my PC)
 with the command : psql -h 127.0.0.1 -d MDI_POST -U MDI_POST
 
 I receipt an error message :
 
 psql: não pôde conectar ao servidor: ??
 O servidor está rodando na máquina 127.0.0.1 e aceitando
 conexões TCP/IP na porta 5432?
 You have new mail in /var/spool/mail/root
 [EMAIL PROTECTED] data]#
 
 Please, take a look of the blue text above (in English it means : psql : 
 can't connct to the server : [EMAIL PROTECTED]).
 
 I think the psql is not understanding what -h 127.0.0.1 stands for.
 
 The rule is : only inform -h xxx.xxx.xxx.xxx to remote accesses.
 
 Is this true ?

To me you local PostgreSQL server is not configured to accept TCP/IP
connections.
Can you check the following please:
a) the postgresql.conf file should contain the parameter tcpip_socket
= true
b) the pg_hba.conf should contain a line like this
host  all  all 127.0.0.1 255.255.255.255   password
near the beginning of the file (take care that line order is important
in this file).

After that, restart PostgreSQL and check the connection with psql (psql
-h 127.0.0.1 -d MDI_POST -U MDI_POST) and then with pgAdmin... It should
be ok.

HTH,
Raphaël

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [pgadmin-hackers] Pgadmin III connection error

2005-09-09 Thread blacknoz

Message d'origine
Date: Thu, 08 Sep 2005 15:18:20 -0300
De: Olimpio [EMAIL PROTECTED]
A: [EMAIL PROTECTED]
Sujet: Pgadmin III connection error

Raphael,

Hi,

please post such question to pgadmin-support or pgadmin-hackers, there is more 
chance for you to get a rapid answer and others may benefit from such 
experience :).


I'm trying to connect to a local database with pgadmin and receipt an 
error message : src/common/string.cpp(1060) : assert nLen != (size_t) - 1

Can you give more details please? Which version of pgAdmin are you using? What 
OS (I suppose Debian GNU/Linux as you asked me first)? What exact release of 
the OS?
Can you configure pgAdmin to log debug information and provide the log file 
(beware to clean it from personnal informations if you care)?


The database is running in the same machine I'm using the pgadmin III.

So, it may be the pgAdmin 1.3.x release I made during summer with a connection 
to a local unix socket or are you trying to connect to 127.0.0.1 in tcp mode?


Can you help me ?

I bet everybody here would be glad to help :)

Waiting for your updates concerning this.
Regards,
Raphaël


---(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