Você consegue trazer algum dado do bd remotamente via código?

Na verdade não. Eu conecto no banco só que um select por exemplo:

select * from pessoas;

no computador local eu tenho os dados, no remoto ele diz que não existe o relacionamento pessoas.

Tive um problema parecido e a causa é com relação ao owner/search_path

ALTER USER <db user> SET search_path to <schema>;

ALTER DATABASE <db name> OWNER TO <db user>;
GRANT ALL PRIVILEGES ON DATABASE <db name> to <db user>;


UPDATE pg_class SET relowner = (SELECT oid FROM pg_roles WHERE rolname = '<db user>') 
 WHERE relname IN (SELECT relname FROM pg_class, pg_namespace 
                    WHERE pg_namespace.oid = pg_class.relnamespace AND 
                          pg_namespace.nspname = '<db schema>');

coloca o nome do schema na conexão, o netbeans, por padrão, pega o primeiro schema em ordem alfabética (na hora de montar a conexão vc pode escolher qual conexão é na última página do wizard)

Realmente isso é problema de schema, coloca o schema.nomeDaTabela em seu SQL.
Abs

No entanto utilizei no pgadim 3 a seguinte url:

select * from public.pessoas;

schema: public
tabelta: pessoas

e ele da erro e na executa (erro no public.pessoas)

qual o schema que você está usando? No geral, as configurações padrão do postgre usa com schema ou public ou o nome do próprio usuário.

rubem…

mas mesmo utilizando o mesmo usuario e senha nos dois computadores eu ainda tenho esse problema?

devo executar este codigo no pgadmin3?

evefuji

utilizo o schema public.

Rodando os comandos no pgadmin você garante que o usuário terá acesso padrão ao schema e será dono das tabelas.

outra coisa que me lembrei, no pg_hba, você (acredito que sim) deu permissão para o usuário acessar essa base de dados mesmo que não seja de localhost? E essa permissão é em MD5?

sim coloquei a seguinte linha:

host all all 0.0.0.0/0 md5.

Detalhe utilizo o mesmo usuário de criação do banco “postgres”

problemas…

fui conferir o pg_hba e a linha estava

hos all all 0.0.0.0/0 trust

com o modo md5 eu nao consigo acessar remoto… alguma dica?

o trust vai pegar o usuário do sistema operacional e permitir acesso a qualquer um (independente de ter a senha ou não), melhor e mais seguro colocar md5.

Verifica se a configuração para localhost também está com trust, se tiver, entra pelo localhost e muda a senha do usuário.

entao… localhost acessa normalmente. O problema que no acesso remoto eu nao consigo
acessar a base.

Anteriormente, no começo do post, eu estava acessando a mesma base e nao conseguia visualizar as mesmas
tabelas da base nas duas maquinas.

Possivel problema: quando esta testando instalei o postgresql nas duas maquinas e desinstalei em uma. Esta que nao esta com o postgresql não acessa a base que esta na outra.

Solução: Me enforcar num pé de cebolinha.

ps. Ja fiz o procedimento que o rubem_vieira. Mas nada de acessar

Erro: Impossivel conectar. Não é possivel estabelecer uma conexão para jdbc:postgresql://jef-pc:5432/teste utilizando org.postgresql.Driver (Conexão negada. Verifique se o nome da máquina e a porta estão corretos e se o postmaster está aceitando conexões tcp/ip).

postmaster?

verifica se no postgresql.conf o parâmetro listen_addresses está com o valor *. E também coloca aqui seu pg_hba.conf para vermos.

PostgreSQL Client Authentication Configuration File

===================================================

Refer to the “Client Authentication” section in the PostgreSQL

documentation for a complete description of this file. A short

synopsis follows.

This file controls: which hosts are allowed to connect, how clients

are authenticated, which PostgreSQL user names they can use, which

databases they can access. Records take one of these forms:

local DATABASE USER METHOD [OPTIONS]

host DATABASE USER ADDRESS METHOD [OPTIONS]

hostssl DATABASE USER ADDRESS METHOD [OPTIONS]

hostnossl DATABASE USER ADDRESS METHOD [OPTIONS]

(The uppercase items must be replaced by actual values.)

The first field is the connection type: “local” is a Unix-domain

socket, “host” is either a plain or SSL-encrypted TCP/IP socket,

“hostssl” is an SSL-encrypted TCP/IP socket, and “hostnossl” is a

plain TCP/IP socket.

DATABASE can be “all”, “sameuser”, “samerole”, “replication”, a

database name, or a comma-separated list thereof. The “all”

keyword does not match “replication”. Access to replication

must be enabled in a separate record (see example below).

USER can be “all”, a user name, a group name prefixed with “+”, or a

comma-separated list thereof. In both the DATABASE and USER fields

you can also write a file name prefixed with “@” to include names

from a separate file.

ADDRESS specifies the set of hosts the record matches. It can be a

host name, or it is made up of an IP address and a CIDR mask that is

an integer (between 0 and 32 (IPv4) or 128 (IPv6) inclusive) that

specifies the number of significant bits in the mask. A host name

that starts with a dot (.) matches a suffix of the actual host name.

Alternatively, you can write an IP address and netmask in separate

columns to specify the set of hosts. Instead of a CIDR-address, you

can write “samehost” to match any of the server’s own IP addresses,

or “samenet” to match any address in any subnet that the server is

directly connected to.

METHOD can be “trust”, “reject”, “md5”, “password”, “gss”, “sspi”,

“krb5”, “ident”, “peer”, “pam”, “ldap”, “radius” or “cert”. Note that

“password” sends passwords in clear text; “md5” is preferred since

it sends encrypted passwords.

OPTIONS are a set of options for the authentication in the format

NAME=VALUE. The available options depend on the different

authentication methods – refer to the “Client Authentication”

section in the documentation for a list of which options are

available for which authentication methods.

Database and user names containing spaces, commas, quotes and other

special characters must be quoted. Quoting one of the keywords

“all”, “sameuser”, “samerole” or “replication” makes the name lose

its special character, and just match a database or username with

that name.

This file is read on server startup and when the postmaster receives

a SIGHUP signal. If you edit the file on a running system, you have

to SIGHUP the postmaster for the changes to take effect. You can

use “pg_ctl reload” to do that.

Put your actual configuration here

----------------------------------

If you want to allow non-local connections, you need to add more

“host” records. In that case you will also need to make PostgreSQL

listen on a non-local interface via the listen_addresses

configuration parameter, or via the -i or -h command line switches.

TYPE DATABASE USER ADDRESS METHOD

IPv4 local connections:

#host all all 127.0.0.1/32 md5

IPv6 local connections:

#host all all ::1/128 md5

Allow replication connections from localhost, by a user with the

replication privilege.

#host replication postgres 127.0.0.1/32 md5
#host replication postgres ::1/128 md5
host all all 0.0.0.0/0 md5

verificou o parâmetro listen_addresses no postgresql.conf?

No pg_hba parece estar certo (numa olhada rápida), faz o seguinte, se conecta de localhost com o usuário e a senha que você configurou, muda a senha desse usuário, e tenta depois conectar da outra máquina.

esta: listen_addresses = ‘*’

Galera… resolvido com algo simples.

Desativei o firewall do windows. Mesmo colocando o psql.exe, a porta 5432 (TCP e UDP) como exceções o firewall estava bloqueando.

Obrigado a todos.