Re: [pgbr-geral] [off topic] PgDAC

[Edson - Listas]

Em 11-07-2013 18:03, Carlos Antônio Pereira (VidaUTI) escreveu:

Obrigado Edson. Certamente farei.
Qual é a versão recomendada?
*From:* Edson Lidorio 
*Sent:* Thursday, July 11, 2013 1:50 PM
*To:* Comunidade PostgreSQL Brasileira 


*Subject:* Re: [pgbr-geral] [off topic] PgDAC
Seria interessante fazer uns teste com Zeos, conexão nativa com vários 
Dbs.

http://zeos.firmos.at/




2013/7/11 izaque Maciel >


Talvez, mesmo que dê mais trabalho, uma opção poderia ser o
DBExpress, com o Drive da Devart.


Em 11 de julho de 2013 11:53, Carlos Antônio Pereira (VidaUTI)
mailto:carlosanto...@utivida.com.br>> escreveu:

*From:* Douglas Fabiano Specht 
*Sent:* Thursday, July 11, 2013 8:30 AM
*To:* Comunidade PostgreSQL Brasileira

*Subject:* Re: [pgbr-geral] [off topic] PgDAC


Em 11 de julho de 2013 00:19, Carlos Antônio Pereira (VidaUTI)
mailto:carlosanto...@utivida.com.br>> escreveu:

Boa noite, senhores.
Estou fazendo a migração de um sistema
de Delphi 5 para Delphi 6
e mudando os componentes de conexão TQuery para TPgQuery
que faz parte do componente PgDAC da Devart.
Os componentes PgDAC acabam com a camada BDE e ODBC.
Sendo assim, deveria apresentar perfomance bem melhor já
que serão duas camadas a menos para acessar os dados
.
O problema é que essa conexão PgDAC que deveria ser muito
mais
rápida está muito mais lenta.  Como estes componentes PgDAC
tem muitas propriedades, imagino que isso seja alguma
configuração.
Estou mudando o servidor também. Essa nova configuração
está sendo
montanda em um PowerEdge T320 com 16 Gb de RAM e HDs SAS de
600 gb RAID 1,  com o PostgreSQL 9.2.
Alguém que usa esse componente pode me ajudar?
Att Carlos

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br

https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral



Bom dia Carlos,
fizemos isso no ano passado em nossa aplicação, mas devido a
estrutura de nossa aplicação e banco, não ganhamos muito em
performance.
Ganhamos sim em independência de Plataforma, de banco e na
facil manutenção.
por acaso vcs nao deixaram o monitor de captura de comandos
sql sempre ativo?
-- 
Douglas Fabiano Specht


Bom dia, Douglas. Antes de tudo agradeço sua resposta.
Então, como os compontes PgDAC são vastos em propriedades,
ainda não me aprofundei em tudo.
Eu já tinha feito um teste com os componentes Zeos mas como
este já não é atualizado há bastante tempo, resolvi investir no
PgDAC que está em constante evolução.
Também bolei uma forma bem prática de substituir os componentes
através da edição do arquivo .dfm e com Replace fazer a troca
das classes,
o que aumenta minha produtividade na conversão.
Os componentes TQuery (BDE) foram migrados para TPgQuery e TPgSQL.
Não consegui rodar comandos em bloco pelo TPgQuery.
Assim, Alguns scripts são rodados em TPgSQL que permite essa
execução
de blocos de comandos SQL.
O PgQuery e PgSQL estão com as configurações padrão do
componte e algumas
consultas fazem update insert e delete, mas a maioria apenas
select.
No Módulo da Central de Operações tem umas 300 querys e é onde dá
para se notar que o PgDAC diminuiu muito a performance em
relação aos
componentes BDE.
Esse monitor de captura de comandos é habilitado na PgQuery?

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br

https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br

https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


___

Re: [pgbr-geral] [off topic] PgDAC

[Edson - Listas]

Em 11-07-2013 20:08, Willian Jhonnes escreveu:
Em 11 de julho de 2013 17:57, Carlos Antônio Pereira (VidaUTI) 
mailto:carlosanto...@utivida.com.br>> 
escreveu:


Não encontrei essa opção Direct. No caso, ela marcada como true
usa a libpq.dll?


Na PgConnection, ao clicar com o botão direito do mouse, acessando o 
menu de contexto, selecione a opção Configure connection. No 
formulário de configuração, acesse a aba Options.


É exatamente ao contrário. Marcada como Direct = True, ele acessa o PG 
através do seu wrapper. Você desmarcará esta opção caso a versão do PG 
não seja suportada pelo wrapper e você precise usar o cliente.


Seria necessario apenas o libpq para funcionar ou teria outros
.dll para adicionar no system32?


Com o Zeos, existe uma lista. Não posso precisar qual, mas é uma 
porção das bibliotecas distribuídas com o PgAdmin III para Windows.


Essa libpq já reconheceria o Pg9 64bits o tem atualizações?


O ideal é que você utilize clientes libpq da mesma versão ou de verões 
superiores em relação ao SGBD, nunca abaixo, como você relatou.


Estou entrando em contato com a Devart...
Att Carlos



--

---
Att.:
Willian Jhonnes L. dos Santos
Analista/Desenvolvedor Object/Free Pascal
Analista/Desenvolvedor PHP
willianjhon...@gmail.com 
---
Engenharia da Computação - PUC-PR
Seja livre. Use Linux.
Grupo de Usuários GNU/Linux de São José dos Pinhais
Linux user number 449753
---
Powered by Slackware Linux 14 64 bits
Kernel 3.7.2-x86_64-iCore
---


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Eu uso Postgresql com Zeos  e CentOs 64 e funciona muito bem.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] [off topic] PgDAC

[Willian Jhonnes]

Em 11 de julho de 2013 17:57, Carlos Antônio Pereira (VidaUTI) <
carlosanto...@utivida.com.br> escreveu:

>   Não encontrei essa opção Direct. No caso, ela marcada como true usa a
> libpq.dll?
>

Na PgConnection, ao clicar com o botão direito do mouse, acessando o menu
de contexto, selecione a opção Configure connection. No formulário de
configuração, acesse a aba Options.

É exatamente ao contrário. Marcada como Direct = True, ele acessa o PG
através do seu wrapper. Você desmarcará esta opção caso a versão do PG não
seja suportada pelo wrapper e você precise usar o cliente.


>  Seria necessario apenas o libpq para funcionar ou teria outros .dll para
> adicionar no system32?
>

Com o Zeos, existe uma lista. Não posso precisar qual, mas é uma porção das
bibliotecas distribuídas com o PgAdmin III para Windows.


> Essa libpq já reconheceria o Pg9 64bits o tem atualizações?
>

O ideal é que você utilize clientes libpq da mesma versão ou de verões
superiores em relação ao SGBD, nunca abaixo, como você relatou.


> Estou entrando em contato com a Devart...
>
> Att Carlos
>



-- 

---
Att.:
Willian Jhonnes L. dos Santos
Analista/Desenvolvedor Object/Free Pascal
Analista/Desenvolvedor PHP
willianjhon...@gmail.com
---
Engenharia da Computação - PUC-PR
Seja livre. Use Linux.
Grupo de Usuários GNU/Linux de São José dos Pinhais
Linux user number 449753
---
Powered by Slackware Linux 14 64 bits
Kernel 3.7.2-x86_64-iCore
---
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] [off topic] PgDAC

[VidaUTI]

Obrigado Edson. Certamente farei.
Qual é a versão recomendada?


From: Edson Lidorio 
Sent: Thursday, July 11, 2013 1:50 PM
To: Comunidade PostgreSQL Brasileira 
Subject: Re: [pgbr-geral] [off topic] PgDAC

Seria interessante fazer uns teste com Zeos, conexão nativa com vários Dbs.
http://zeos.firmos.at/






2013/7/11 izaque Maciel 

  Talvez, mesmo que dê mais trabalho, uma opção poderia ser o DBExpress, com o 
Drive da Devart.



  Em 11 de julho de 2013 11:53, Carlos Antônio Pereira (VidaUTI) 
 escreveu:

From: Douglas Fabiano Specht 
Sent: Thursday, July 11, 2013 8:30 AM
To: Comunidade PostgreSQL Brasileira 
Subject: Re: [pgbr-geral] [off topic] PgDAC





Em 11 de julho de 2013 00:19, Carlos Antônio Pereira (VidaUTI) 
 escreveu:

  Boa noite, senhores.
  Estou fazendo a migração de um sistema de Delphi 5 para Delphi 6
  e mudando os componentes de conexão TQuery para TPgQuery
  que faz parte do componente PgDAC da Devart.
  Os componentes PgDAC acabam com a camada BDE e ODBC.
  Sendo assim, deveria apresentar perfomance bem melhor já
  que serão duas camadas a menos para acessar os dados.
  O problema é que essa conexão PgDAC que deveria ser muito mais 
  rápida está muito mais lenta.  Como estes componentes PgDAC
  tem muitas propriedades, imagino que isso seja alguma configuração.
  Estou mudando o servidor também. Essa nova configuração está sendo
  montanda em um PowerEdge T320 com 16 Gb de RAM e HDs SAS de 
  600 gb RAID 1,  com o PostgreSQL 9.2. 
  Alguém que usa esse componente pode me ajudar?
  Att Carlos   

  ___
  pgbr-geral mailing list
  pgbr-geral@listas.postgresql.org.br
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral





Bom dia Carlos,

fizemos isso no ano passado em nossa aplicação, mas devido a estrutura de 
nossa aplicação e banco, não ganhamos muito em performance.
Ganhamos sim em independência de Plataforma, de banco e na facil manutenção.
por acaso vcs nao deixaram o monitor de captura de comandos sql sempre 
ativo?


-- 


Douglas Fabiano Specht




Bom dia, Douglas. Antes de tudo agradeço sua resposta.
Então, como os compontes PgDAC são vastos em propriedades,
ainda não me aprofundei em tudo.

Eu já tinha feito um teste com os componentes Zeos mas como
este já não é atualizado há bastante tempo, resolvi investir no
PgDAC que está em constante evolução.

Também bolei uma forma bem prática de substituir os componentes
através da edição do arquivo .dfm e com Replace fazer a troca das classes,
o que aumenta minha produtividade na conversão.

Os componentes TQuery (BDE) foram migrados para TPgQuery e TPgSQL.
Não consegui rodar comandos em bloco pelo TPgQuery. 
Assim, Alguns scripts são rodados em TPgSQL que permite essa execução
de blocos de comandos SQL.

O PgQuery e PgSQL estão com as configurações padrão do componte e algumas
consultas fazem update insert e delete, mas a maioria apenas select.

No Módulo da Central de Operações tem umas 300 querys e é onde dá 
para se notar que o PgDAC diminuiu muito a performance em relação aos 
componentes BDE.

Esse monitor de captura de comandos é habilitado na PgQuery? 

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral




  ___
  pgbr-geral mailing list
  pgbr-geral@listas.postgresql.org.br
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral






___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] [off topic] PgDAC

[VidaUTI]

Não encontrei essa opção Direct. No caso, ela marcada como true usa a 
libpq.dll? 
Seria necessario apenas o libpq para funcionar ou teria outros .dll para 
adicionar no system32?
Essa libpq já reconheceria o Pg9 64bits o tem atualizações?
Estou entrando em contato com a Devart...

Att Carlos
From: Willian Jhonnes 
Sent: Thursday, July 11, 2013 5:04 PM
To: Comunidade PostgreSQL Brasileira 
Subject: Re: [pgbr-geral] [off topic] PgDAC

Em 11 de julho de 2013 16:43, Carlos Antônio Pereira (VidaUTI) 
 escreveu:

  Obrigado, Willian.

  Então vou ter que avaliar melhor minha decisão entre Zeos e PpDAC...
  Respondendo às suas perguntas:

  1) Estou acessando diretamente (somente colocando as DLLS no local destinado).
  2) Estou usando a libpq.dll versão 8.4.17, modificada em 02/04/2013.
  3) Servidor Linux Fedora 19 64 bits, PostgreSQL 9.2.4 X64.

O acesso direto pode ser verificado nas opções específicas (SpecificOptions) do 
PgDAC (opção Direct = True).


  Sim. Comprei os compontes PgDAC em fevereiro deste ano. 

  Eu fiz uns testes aqui apagando todas as dlls e o sistema continua 
funcionando.
  Os componentes funcionam sem as bibliotecas?

Sim. Ele tem, internamente, o wrapper do cliente libpq.

O que pode ocorrer, no seu caso, é algum problema relativo ao componente. Como 
pode ser visto em [1], há algumas questões sobre este assunto 
(performance/lentidão). Dá uma olhada lá. De repente, algo por lá te ajuda.

[1] - http://forums.devart.com/viewforum.php?f=34

-- 


---
Att.:
Willian Jhonnes L. dos Santos
Analista/Desenvolvedor Object/Free Pascal
Analista/Desenvolvedor PHP
willianjhon...@gmail.com
--- 
Engenharia da Computação - PUC-PR
Seja livre. Use Linux.
Grupo de Usuários GNU/Linux de São José dos Pinhais
Linux user number 449753
---
Powered by Slackware Linux 14 64 bits
Kernel 3.7.2-x86_64-iCore 
---



___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] [off topic] PgDAC

[Willian Jhonnes]

Em 11 de julho de 2013 16:43, Carlos Antônio Pereira (VidaUTI) <
carlosanto...@utivida.com.br> escreveu:

>   Obrigado, Willian.
>
> Então vou ter que avaliar melhor minha decisão entre Zeos e PpDAC...
> Respondendo às suas perguntas:
>
> 1) Estou acessando diretamente (somente colocando as DLLS no local
> destinado).
> 2) Estou usando a libpq.dll versão 8.4.17, modificada em 02/04/2013.
> 3) Servidor Linux Fedora 19 64 bits, PostgreSQL 9.2.4 X64.
>

O acesso direto pode ser verificado nas opções específicas
(SpecificOptions) do PgDAC (opção Direct = True).


>
> Sim. Comprei os compontes PgDAC em fevereiro deste ano.
>
> Eu fiz uns testes aqui apagando todas as dlls e o sistema continua
> funcionando.
> Os componentes funcionam sem as bibliotecas?
>

Sim. Ele tem, internamente, o wrapper do cliente libpq.

O que pode ocorrer, no seu caso, é algum problema relativo ao componente.
Como pode ser visto em [1], há algumas questões sobre este assunto
(performance/lentidão). Dá uma olhada lá. De repente, algo por lá te ajuda.

[1] - http://forums.devart.com/viewforum.php?f=34

-- 

---
Att.:
Willian Jhonnes L. dos Santos
Analista/Desenvolvedor Object/Free Pascal
Analista/Desenvolvedor PHP
willianjhon...@gmail.com
---
Engenharia da Computação - PUC-PR
Seja livre. Use Linux.
Grupo de Usuários GNU/Linux de São José dos Pinhais
Linux user number 449753
---
Powered by Slackware Linux 14 64 bits
Kernel 3.7.2-x86_64-iCore
---
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Permissões e Restrições de acesso a banco

[Fábio Telles Rodriguez]

Em 11 de julho de 2013 10:30, Paulo Bastos  escreveu:

> Senhores(as),
>
> executei o comando
>
> REVOKE ALL PRIVILEGES ON SCHEMA ap FROM cpdsocic_group - Este funciona.
> Porem teria que tirar a permissão esquema por esquema.
> Poderia executar um script. Porem tenho vários esquemas com várias tabelas
> e vários bancos.
> Tentei
>
> REVOKE ALL PRIVILEGES ON DATABASE socic_ponto FROM cpdsocic_group; -
> Executou sem problemas. POrem continuo tendo acesso
> as tabelas deste esquema.
>
> Tentei
>
> REVOKE ALL PRIVILEGES ON DATABASE socic_ponto FROM cpdsocic; - Executou
> também. POrem continuo tendo acesso as tabelas. Estou checando pelo
> pg_admin, utilizando o usuário cpdsocic que faz parte do grupo
> cpdsocic_group.
>


Tente também um REVOKE ALL  FROM PUBLIC;

-- 
Atenciosamente,
Fábio Telles Rodriguez
blog: http:// s
avepoint.blog.br
e-mail / gtalk / MSN: fabio.tel...@gmail.com
Skype: fabio_telles

Timbira - A empresa brasileira de Postgres
http://www.timbira.com.br
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] [off topic] PgDAC

[VidaUTI]

Obrigado, Willian.

Então vou ter que avaliar melhor minha decisão entre Zeos e PpDAC...
Respondendo às suas perguntas:

1) Estou acessando diretamente (somente colocando as DLLS no local destinado).
2) Estou usando a libpq.dll versão 8.4.17, modificada em 02/04/2013.
3) Servidor Linux Fedora 19 64 bits, PostgreSQL 9.2.4 X64.

Sim. Comprei os compontes PgDAC em fevereiro deste ano. 

Eu fiz uns testes aqui apagando todas as dlls e o sistema continua funcionando.
Os componentes funcionam sem as bibliotecas? 

   

From: Willian Jhonnes 
Sent: Thursday, July 11, 2013 1:59 PM
To: Comunidade PostgreSQL Brasileira 
Subject: Re: [pgbr-geral] [off topic] PgDAC

Em 11 de julho de 2013 11:53, Carlos Antônio Pereira (VidaUTI) 
 escreveu:



  Eu já tinha feito um teste com os componentes Zeos mas como
  este já não é atualizado há bastante tempo, resolvi investir no
  PgDAC que está em constante evolução.

Na verdade, não. O repositório SVN tem bastante movimento. Hoje mesmo fiz a 
atualização e os fontes da versão 7.1 beta e 7.2 testing estão disponíveis.

Perguntas sobre o seu caso:

1) Você está acessando o PostgreSQL em modo direto pelo PgDAC?
2) Se não, qual a biblioteca cliente utilizada (nome/versão)?
3) Qual a versão e a plataforma do servidor PostgreSQL?

Componentes da DevArt são muito bons, sendo mais rápidos que o DBExpress, o BDE 
e o ADO. O Zeos, hoje, é mais rápido, mas até hoje, só pode ser utilizado com 
servidores 32 bits.

Se você adquiriu os componentes, você pode verificar estas questões diretamente 
com o suporte da DevArt. Senão, o fórum deles também pode ajudar, já que é 
mantido por desenvolvedores da própria DevArt.


-- 


---
Att.:
Willian Jhonnes L. dos Santos
Analista/Desenvolvedor Object/Free Pascal
Analista/Desenvolvedor PHP
willianjhon...@gmail.com
--- 
Engenharia da Computação - PUC-PR
Seja livre. Use Linux.
Grupo de Usuários GNU/Linux de São José dos Pinhais
Linux user number 449753
---
Powered by Slackware Linux 14 64 bits
Kernel 3.7.2-x86_64-iCore 
---



___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação nativa do postgresql 9.2 com problema

[Flavio Henrique Araque Gurgel]

Em 11-07-2013 16:22, Deliane Andrade escreveu:

Vamos lá!

"Qual a saída completa do comando: SELECT version(); "
 >> postgres=# SELECT version();
version
--
  PostgreSQL 9.2.2 on x86_64-unknown-linux-gnu, compiled by gcc (Debian
4.4.5-8) 4.4.5, 64-bit
(1 registro)


Ok, GCC 4.4.5 não é afetado pelo bug.


"Verifique se seu PostgreSQL foi compilado com gcc 4.6.0 - tem um bug
relacionado a isso. Como foi feita a instalação do seu PostgreSQL? "
 >>
root@condor:/dbprod/data#  gcc --version
gcc (Debian 4.4.5-8) 4.4.5


Esta é a versão do gcc em seu S.O. e não a que compilou o PostgreSQL 
(que está na saída do version, acima).




" Esta é a versão só do psql ou do servidor também?
Verifique. Atualize imediatamente."


A versão do  Postgresql instalado é a 9.2.2 -- não posso trocar de
versão no momento,pois está em produção.


Na próxima janela possível, atualize. Tem bugs graves!


" Inclua --delete na sua linha de comando do rsync pra não ficar
lotando o espaço no seu escravo."
 >> OK

 >> Assíncrona.


OK.

De acordo com:
http://www.postgresql.org/message-id/caa11fe2.1dde2%linas.virba...@continuent.com

Um colega que já passou por isso fez uma mudança de procedimento ao 
executar o início do backup, com:

SELECT pg_start_backup('nome', true);

E resolveu o problema.

É um caso de que alguns segmentos de log de transação faltaram pra 
tornar o backup válido. Com o "true" no comando, um checkpoint será 
forçado no início do backup, terminando o anterior imediatamente, ao 
invés de esperar. Isso torna a sequência de logs de transação 
necessários à restauração correta.


Teste e nos avise se deu certo, por favor.

[]s

__
Flavio Henrique A. Gurgel
Líder de Projetos Especiais
Consultoria, Projetos & Treinamentos 4LINUX
Tel1: +55-11.2125-4747 ou 2125-4748
www.4linux.com.br
email: fla...@4linux.com.br
__
FREE SOFTWARE SOLUTIONS
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação nativa do postgresql 9.2 com problema

[Deliane Andrade]

Desculpem faltou  um tópico:

"Apenas as configurações de replicação do postgresql.conf do escravo (grupo
Standby Servers do arquivo)."

>
>>
#--
# REPLICATION
#--

# - Standby Servers -

# These settings are ignored on a master server.

hot_standby = on# "on" allows queries during
recovery
# (change requires restart)
#max_standby_archive_delay = 30s# max delay before canceling queries
# when reading WAL from archive;
# -1 allows indefinite delay
#max_standby_streaming_delay = 30s  # max delay before canceling queries
# when reading streaming WAL;
# -1 allows indefinite delay
#wal_receiver_status_interval = 10s # send replies at least this often
# 0 disables
#hot_standby_feedback = off # send info from standby to prevent
# query conflicts


Att,
 Deliane Andrade
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação nativa do postgresql 9.2 com problema

[Deliane Andrade]

Vamos lá!

"Qual a saída completa do comando: SELECT version(); "
>> postgres=# SELECT version();
   version
--
 PostgreSQL 9.2.2 on x86_64-unknown-linux-gnu, compiled by gcc (Debian
4.4.5-8) 4.4.5, 64-bit
(1 registro)

"Verifique se seu PostgreSQL foi compilado com gcc 4.6.0 - tem um bug
relacionado a isso. Como foi feita a instalação do seu PostgreSQL? "
>>
root@condor:/dbprod/data#  gcc --version
gcc (Debian 4.4.5-8) 4.4.5
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


> " Esta é a versão só do psql ou do servidor também?
> Verifique. Atualize imediatamente."


A versão do  Postgresql instalado é a 9.2.2 -- não posso trocar de versão
no momento,pois está em produção.


> " Inclua --delete na sua linha de comando do rsync pra não ficar lotando o
> espaço no seu escravo."
> >> OK
>


> " Pode ser o tal bug no gcc. Verifique a versão dele como recomendei mais
> acima.
>
> Sua replicação está em modo síncrono? Se estiver, tente deixá-la
> assíncrona temporariamente e verifique se o problema se resolve."
>

>> Assíncrona.

"Poste aqui por favor:
Como está seu recovery.conf."

 recovery.conf :


> standby_mode = 'on'
> primary_conninfo = 'host=*ip do master* port=5432 user=replicacao
> password=*senha*'
> trigger_file = '/local/script/failover.trg'
>
>

> "Apenas as configurações de replicação do postgresql.conf do mestre (grupo
> Master Servers do arquivo)."
>

>>
#--
# REPLICATION
#--

# - Sending Server(s) -

# Set these on the master and on any standby that will send replication
data.

  # max number of walsender processes
max_wal_senders = 1
# (change requires restart)
# in logfile segments, 16MB
each; 0 disables
wal_keep_segments = 100

#replication_timeout = 60s  # in milliseconds; 0 disables

# - Master Server -

# These settings are ignored on a standby server.

#synchronous_standby_names = '' # standby servers that provide sync rep
# comma-separated list of application_name
# from standby(s); '*' = all
#vacuum_defer_cleanup_age = 0   # number of xacts by which cleanup is
delayed

# - Standby Servers -

# These settings are ignored on a master server.

#hot_standby = on   # "on" allows queries during
recovery
# (change requires restart)
#max_standby_archive_delay = 30s# max delay before canceling queries
# when reading WAL from archive;
# -1 allows indefinite delay
#max_standby_streaming_delay = 30s  # max delay before canceling queries
# when reading streaming WAL;
# -1 allows indefinite delay
#wal_receiver_status_interval = 10s # send replies at least this often
# 0 disables
#hot_standby_feedback = off # send info from standby to prevent
# query conflicts



> Apenas as configurações de replicação do postgresql.conf do escravo (grupo
> Standby Servers do arquivo).
>
> []s
>
> __**
> Flavio Henrique A. Gurgel
> Líder de Projetos Especiais
> Consultoria, Projetos & Treinamentos 4LINUX
> Tel1: +55-11.2125-4747 ou 2125-4748
> www.4linux.com.br
> email: fla...@4linux.com.br
> __
> FREE SOFTWARE SOLUTIONS
> __**_
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.**org.br
> https://listas.postgresql.org.**br/cgi-bin/mailman/listinfo/**pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação nativa do postgresql 9.2 com problema

[Flavio Henrique Araque Gurgel]

Em 11-07-2013 15:37, Deliane Andrade escreveu:

Olá, boa tarde.

Pessoal, tenho um servidor master e um slave que estava trabalhando
normalmente com a replicação nativa.
Notei que quando o script de vacuum/backup entra em ação todo dia às
00:00h a replicação é parada.


Qual a saída completa do comando:
SELECT version();

Verifique se seu PostgreSQL foi compilado com gcc 4.6.0 - tem um bug 
relacionado a isso. Como foi feita a instalação do seu PostgreSQL?



Tentei refazer o rsync ,mas quanto tento dar o start no slave o mesmo
não inicia o serviço do postgresql.

O log me informa o seguinte:

<%%2013-07-11 15:23:49.902 BRT>LOG:  sistema de banco de dados foi
interrompido; última execução em 2013-07-11 15:24:57 BRT
<%%2013-07-11 15:23:49.903 BRT>LOG:  entrando no modo em espera
<%%2013-07-11 15:23:49.908 BRT>LOG:  replicação em fluxo conectou-se
com sucesso ao servidor principal
<%%2013-07-11 15:23:50.235 BRT>LOG:  redo inicia em B72/3420
<%%2013-07-11 15:23:50.236 BRT>FATAL:  não pôde acessar status da
transação 65598726
<%%2013-07-11 15:23:50.236 BRT>DETALHE:  não pôde ler do arquivo
"pg_clog/003E" deslocado de 139264: Sucesso.
<%%2013-07-11 15:23:50.236 BRT>CONTEXTO:  redo do xlog commit:
2013-07-11 15:24:58.009033-03
<%%2013-07-11 15:23:50.237 BRT>LOG:  processo de inicialização (PID
1719) terminou com código de retorno 1
<%%2013-07-11 15:23:50.237 BRT>LOG:  terminando quaisquer outros
processos servidor ativos
~


Resumindo, mesmo refazendo todo o processo  da forma abaixo :

MASTER :
postgres@condor:~$ psql

postgres@condor:~$ psql
psql (9.2.2)


Esta é a versão só do psql ou do servidor também?
Verifique. Atualize imediatamente.


Digite "help" para ajuda.

postgres=# select pg_start_backup('replicacao', true);

postgres=# \q

postgres@condor:~$ rsync -a -v -e ssh /dbprod/data/
postgres@192.168.200.45:/dbprod/data/ --exclude postmaster.pid --exclude
postgresql.conf --exclude pg_hba.conf


Inclua --delete na sua linha de comando do rsync pra não ficar lotando o 
espaço no seu escravo.



postgres@condor:~$ psql

postgres@condor:~$ psql
psql (9.2.2)
Digite "help" para ajuda.

postgres=# select pg_stop_backup();


SLAVE :
root@cidadevelha:/dbprod/data/pg_log# /etc/init.d/postgres start
Starting PostgreSQL: ok

root@cidadevelha:/dbprod/data/pg_log# /etc/init.d/postgres status
pg_ctl: nenhum servidor está executando
root@cidadevelha:/dbprod/data/pg_log#

O meu SLAVE não sobe.
A mensagem do log a citada anteriormente.
Alguém teria idéia do que esteja acontecendo?


Pode ser o tal bug no gcc. Verifique a versão dele como recomendei mais 
acima.


Sua replicação está em modo síncrono? Se estiver, tente deixá-la 
assíncrona temporariamente e verifique se o problema se resolve.


Poste aqui por favor:
Como está seu recovery.conf.
Apenas as configurações de replicação do postgresql.conf do mestre 
(grupo Master Servers do arquivo).
Apenas as configurações de replicação do postgresql.conf do escravo 
(grupo Standby Servers do arquivo).


[]s

__
Flavio Henrique A. Gurgel
Líder de Projetos Especiais
Consultoria, Projetos & Treinamentos 4LINUX
Tel1: +55-11.2125-4747 ou 2125-4748
www.4linux.com.br
email: fla...@4linux.com.br
__
FREE SOFTWARE SOLUTIONS
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Replicação nativa do postgresql 9.2 com problema

[Deliane Andrade]

Olá, boa tarde.

Pessoal, tenho um servidor master e um slave que estava trabalhando
normalmente com a replicação nativa.
Notei que quando o script de vacuum/backup entra em ação todo dia às 00:00h
a replicação é parada.
Tentei refazer o rsync ,mas quanto tento dar o start no slave o mesmo não
inicia o serviço do postgresql.

O log me informa o seguinte:

<%%2013-07-11 15:23:49.902 BRT>LOG:  sistema de banco de dados foi
interrompido; última execução em 2013-07-11 15:24:57 BRT
<%%2013-07-11 15:23:49.903 BRT>LOG:  entrando no modo em espera
<%%2013-07-11 15:23:49.908 BRT>LOG:  replicação em fluxo conectou-se com
sucesso ao servidor principal
<%%2013-07-11 15:23:50.235 BRT>LOG:  redo inicia em B72/3420
<%%2013-07-11 15:23:50.236 BRT>FATAL:  não pôde acessar status da
transação 65598726
<%%2013-07-11 15:23:50.236 BRT>DETALHE:  não pôde ler do arquivo
"pg_clog/003E" deslocado de 139264: Sucesso.
<%%2013-07-11 15:23:50.236 BRT>CONTEXTO:  redo do xlog commit: 2013-07-11
15:24:58.009033-03
<%%2013-07-11 15:23:50.237 BRT>LOG:  processo de inicialização (PID 1719)
terminou com código de retorno 1
<%%2013-07-11 15:23:50.237 BRT>LOG:  terminando quaisquer outros processos
servidor ativos
~


Resumindo, mesmo refazendo todo o processo  da forma abaixo :

MASTER :
postgres@condor:~$ psql

postgres@condor:~$ psql
psql (9.2.2)
Digite "help" para ajuda.

postgres=# select pg_start_backup('replicacao', true);

postgres=# \q

postgres@condor:~$ rsync -a -v -e ssh /dbprod/data/
postgres@192.168.200.45:/dbprod/data/
--exclude postmaster.pid --exclude postgresql.conf --exclude pg_hba.conf

postgres@condor:~$ psql

postgres@condor:~$ psql
psql (9.2.2)
Digite "help" para ajuda.

postgres=# select pg_stop_backup();


SLAVE :
root@cidadevelha:/dbprod/data/pg_log# /etc/init.d/postgres start
Starting PostgreSQL: ok

root@cidadevelha:/dbprod/data/pg_log# /etc/init.d/postgres status
pg_ctl: nenhum servidor está executando
root@cidadevelha:/dbprod/data/pg_log#

O meu SLAVE não sobe.
A mensagem do log a citada anteriormente.
Alguém teria idéia do que esteja acontecendo?

Agradeço a atenção.

Deliane Andrade
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] ACESSAR PG EM COMPUTADOR DUAL BOOT

[Flavio Henrique Araque Gurgel]

Como *não* responder em top-post:


1. Não dá pra colocar o cluster em uma partição FAT e lê-la no Windows?
Desempenho ficaria bem ruim, mas ainda assim os arquivos do cluster são
diferentes?


Não.


2. Supondo que o cluster esteja em ext4, não daria pra usar um algo
parecido como Ext2Fsd para tratar a partição como nativa no Windows?


Não.


3. O contrário é possível, via ntfs-3g? A estrutura do cluster é a mesma
em ambos SOs, mudando o PG_DATA?


Não.

O sistema de arquivos não é a questão, mas o S.O. Um cluster criado em 
Windows não funciona no Linux e vice-versa.


Em tempo, não dá pra usar PostgreSQL em FAT e seus comparsas. No 
Windows, sua única opção é o NTFS.


Viu como fica mais fácil entender um e-mail quando não se usa 
top-posting? Respondo cada uma de suas perguntas e você entende tudo.


[]s

__
Flavio Henrique A. Gurgel
Líder de Projetos Especiais
Consultoria, Projetos & Treinamentos 4LINUX
Tel1: +55-11.2125-4747 ou 2125-4748
www.4linux.com.br
email: fla...@4linux.com.br
__
FREE SOFTWARE SOLUTIONS
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] ACESSAR PG EM COMPUTADOR DUAL BOOT

[Bruno Simioni]

1. Não dá pra colocar o cluster em uma partição FAT e lê-la no Windows?
Desempenho ficaria bem ruim, mas ainda assim os arquivos do cluster são
diferentes?

2. Supondo que o cluster esteja em ext4, não daria pra usar um algo
parecido como Ext2Fsd para tratar a partição como nativa no Windows?

3. O contrário é possível, via ntfs-3g? A estrutura do cluster é a mesma em
ambos SOs, mudando o PG_DATA?

Bruno


2013/7/11 Flavio Henrique Araque Gurgel 

> Em 11-07-2013 14:59, Eduardo Az -EMBRASIS escreveu:
>
>> Pergunta:
>> É POSSIVEL INSTALAR O PG NO LINUX UBUNTU E ELE ACESSAR ESTA BASE CRIADA
>> NO WINDOWS?
>>
>
> Não.
> []s
>
> __**
> Flavio Henrique A. Gurgel
> Líder de Projetos Especiais
> Consultoria, Projetos & Treinamentos 4LINUX
> Tel1: +55-11.2125-4747 ou 2125-4748
> www.4linux.com.br
> email: fla...@4linux.com.br
> __
> FREE SOFTWARE SOLUTIONS
> __**_
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.**org.br
> https://listas.postgresql.org.**br/cgi-bin/mailman/listinfo/**pgbr-geral
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] ACESSAR PG EM COMPUTADOR DUAL BOOT

[Flavio Henrique Araque Gurgel]

Em 11-07-2013 14:59, Eduardo Az -EMBRASIS escreveu:

Pergunta:
É POSSIVEL INSTALAR O PG NO LINUX UBUNTU E ELE ACESSAR ESTA BASE CRIADA
NO WINDOWS?


Não.
[]s

__
Flavio Henrique A. Gurgel
Líder de Projetos Especiais
Consultoria, Projetos & Treinamentos 4LINUX
Tel1: +55-11.2125-4747 ou 2125-4748
www.4linux.com.br
email: fla...@4linux.com.br
__
FREE SOFTWARE SOLUTIONS
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] ACESSAR PG EM COMPUTADOR DUAL BOOT

[Eduardo Az -EMBRASIS]

Pessoal

Acredito não ser possivel, mas, vamos lá:

Instalei no meu laptop pg 9.2, com windows 7, consecutivamente, usando NTFS.

Instalei o ubuntu 13.04, sem fazer alterações, com a configuração básica e 
fazendo dual boot para acessar ubuntu ou windows dependendo da necessidade.

O HD dele está particionado, e a instalação da base da dados do pg foi feita na 
unidade “D” do windows.

Pergunta:
É POSSIVEL INSTALAR O PG NO LINUX UBUNTU E ELE ACESSAR ESTA BASE CRIADA NO 
WINDOWS? 

Eduardo Az
EMBRASIS

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] RES: [off topic] PgDAC

[Willian Jhonnes]

Em 11 de julho de 2013 14:42, jpaulorieg  escreveu:

> O Zeos, hoje, é mais rápido, mas até hoje, só pode ser utilizado com
> servidores 32 bits.
>
> Muito pelo contrário, eu só utilizo o PostgreSQL x64  e conecto nele
> através do ZEOS. Minha aplicação local é x86, mas a carga do sistema é bem
> distribuída, e rotinas pesadas mantenho no servidor. E o ZEOS é muito
> compatível com o postgres e a performance não deixa a desejar.
>

Na última avaliação que fiz (versão 7.0.2 stable), o Zeos só funcionava com
a libpq para 32 bits, tanto Windows quanto Linux e FreeBSD. Vou reavaliar
esta questão, pois adotei, provisoriamente, o UniDAC da DevArt como
solução. Pode ser que isto tenha sido revisto na versão "trunk", mas até
maio (quando testei este cenário), era impossível.

-- 

---
Att.:
Willian Jhonnes L. dos Santos
Analista/Desenvolvedor Object/Free Pascal
Analista/Desenvolvedor PHP
willianjhon...@gmail.com
---
Engenharia da Computação - PUC-PR
Seja livre. Use Linux.
Grupo de Usuários GNU/Linux de São José dos Pinhais
Linux user number 449753
---
Powered by Slackware Linux 14 64 bits
Kernel 3.7.2-x86_64-iCore
---
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] RES: [off topic] PgDAC

[jpaulorieg]

 

 

 

Em 11 de julho de 2013 11:53, Carlos Antônio Pereira (VidaUTI)
mailto:carlosanto...@utivida.com.br> >
escreveu:

 

 

Eu já tinha feito um teste com os componentes Zeos mas como

este já não é atualizado há bastante tempo, resolvi investir no

PgDAC que está em constante evolução.

 

Na verdade, não. O repositório SVN tem bastante movimento. Hoje mesmo fiz a
atualização e os fontes da versão 7.1 beta e 7.2 testing estão disponíveis.

 

Perguntas sobre o seu caso:

 

1) Você está acessando o PostgreSQL em modo direto pelo PgDAC?

2) Se não, qual a biblioteca cliente utilizada (nome/versão)?

3) Qual a versão e a plataforma do servidor PostgreSQL?

 

Componentes da DevArt são muito bons, sendo mais rápidos que o DBExpress, o
BDE e o ADO. O Zeos, hoje, é mais rápido, mas até hoje, só pode ser
utilizado com servidores 32 bits.

Muito pelo contrário, eu só utilizo o PostgreSQL x64  e conecto nele através
do ZEOS. Minha aplicação local é x86, mas a carga do sistema é bem
distribuída, e rotinas pesadas mantenho no servidor. E o ZEOS é muito
compatível com o postgres e a performance não deixa a desejar.

 

 

Se você adquiriu os componentes, você pode verificar estas questões
diretamente com o suporte da DevArt. Senão, o fórum deles também pode
ajudar, já que é mantido por desenvolvedores da própria DevArt.


 

-- 

 
---
Att.:
Willian Jhonnes L. dos Santos
Analista/Desenvolvedor Object/Free Pascal
Analista/Desenvolvedor PHP
willianjhon...@gmail.com  
---

Engenharia da Computação - PUC-PR
Seja livre. Use Linux.
Grupo de Usuários GNU/Linux de São José dos Pinhais
Linux user number 449753
---
Powered by Slackware Linux 14 64 bits
Kernel 3.7.2-x86_64-iCore 
---

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] [off topic] PgDAC

[Willian Jhonnes]

Em 11 de julho de 2013 11:53, Carlos Antônio Pereira (VidaUTI) <
carlosanto...@utivida.com.br> escreveu:

>
>
>  Eu já tinha feito um teste com os componentes Zeos mas como
> este já não é atualizado há bastante tempo, resolvi investir no
> PgDAC que está em constante evolução.
>

Na verdade, não. O repositório SVN tem bastante movimento. Hoje mesmo fiz a
atualização e os fontes da versão 7.1 beta e 7.2 testing estão disponíveis.

Perguntas sobre o seu caso:

1) Você está acessando o PostgreSQL em modo direto pelo PgDAC?
2) Se não, qual a biblioteca cliente utilizada (nome/versão)?
3) Qual a versão e a plataforma do servidor PostgreSQL?

Componentes da DevArt são muito bons, sendo mais rápidos que o DBExpress, o
BDE e o ADO. O Zeos, hoje, é mais rápido, mas até hoje, só pode ser
utilizado com servidores 32 bits.

Se você adquiriu os componentes, você pode verificar estas questões
diretamente com o suporte da DevArt. Senão, o fórum deles também pode
ajudar, já que é mantido por desenvolvedores da própria DevArt.

-- 

---
Att.:
Willian Jhonnes L. dos Santos
Analista/Desenvolvedor Object/Free Pascal
Analista/Desenvolvedor PHP
willianjhon...@gmail.com
---
Engenharia da Computação - PUC-PR
Seja livre. Use Linux.
Grupo de Usuários GNU/Linux de São José dos Pinhais
Linux user number 449753
---
Powered by Slackware Linux 14 64 bits
Kernel 3.7.2-x86_64-iCore
---
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] [off topic] PgDAC

[Edson Lidorio]

Seria interessante fazer uns teste com Zeos, conexão nativa com vários Dbs.
http://zeos.firmos.at/




2013/7/11 izaque Maciel 

> Talvez, mesmo que dê mais trabalho, uma opção poderia ser o DBExpress, com
> o Drive da Devart.
>
>
> Em 11 de julho de 2013 11:53, Carlos Antônio Pereira (VidaUTI) <
> carlosanto...@utivida.com.br> escreveu:
>
>>   *From:* Douglas Fabiano Specht 
>>  *Sent:* Thursday, July 11, 2013 8:30 AM
>> *To:* Comunidade PostgreSQL Brasileira
>> *Subject:* Re: [pgbr-geral] [off topic] PgDAC
>>
>>
>>
>>
>> Em 11 de julho de 2013 00:19, Carlos Antônio Pereira (VidaUTI) <
>> carlosanto...@utivida.com.br> escreveu:
>>
>>>   Boa noite, senhores.
>>>
>>>  Estou fazendo a migração de um sistema
>>> de Delphi 5 para Delphi 6
>>>  e mudando os componentes de conexão TQuery para TPgQuery
>>>
>>> que faz parte do componente PgDAC da Devart.
>>>
>>>  Os componentes PgDAC acabam com a camada BDE e ODBC.
>>>  Sendo assim, deveria apresentar perfomance bem melhor já
>>>  que serão duas camadas a menos para acessar os dados
>>> .
>>>
>>>  O problema é que essa conexão PgDAC que deveria ser muito mais
>>>  rápida está muito mais lenta.  Como estes componentes PgDAC
>>>  tem muitas propriedades, imagino que isso seja alguma configuração.
>>>
>>>  Estou mudando o servidor também. Essa nova configuração está sendo
>>>  montanda em um PowerEdge T320 com 16 Gb de RAM e HDs SAS de
>>>  600 gb RAID 1,  com o PostgreSQL 9.2.
>>>
>>>  Alguém que usa esse componente pode me ajudar?
>>>
>>>  Att Carlos
>>>
>>>
>>>
>>>
>>> ___
>>> pgbr-geral mailing list
>>> pgbr-geral@listas.postgresql.org.br
>>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>>
>>>
>>
>> Bom dia Carlos,
>>
>> fizemos isso no ano passado em nossa aplicação, mas devido a estrutura de
>> nossa aplicação e banco, não ganhamos muito em performance.
>> Ganhamos sim em independência de Plataforma, de banco e na facil
>> manutenção.
>> por acaso vcs nao deixaram o monitor de captura de comandos sql sempre
>> ativo?
>>
>>
>> --
>>
>> Douglas Fabiano Specht
>>
>> --
>>
>> Bom dia, Douglas. Antes de tudo agradeço sua resposta.
>> Então, como os compontes PgDAC são vastos em propriedades,
>> ainda não me aprofundei em tudo.
>>
>>  Eu já tinha feito um teste com os componentes Zeos mas como
>> este já não é atualizado há bastante tempo, resolvi investir no
>> PgDAC que está em constante evolução.
>>
>> Também bolei uma forma bem prática de substituir os componentes
>> através da edição do arquivo .dfm e com Replace fazer a troca das classes,
>> o que aumenta minha produtividade na conversão.
>>
>> Os componentes TQuery (BDE) foram migrados para TPgQuery e TPgSQL.
>> Não consegui rodar comandos em bloco pelo TPgQuery.
>> Assim, Alguns scripts são rodados em TPgSQL que permite essa execução
>> de blocos de comandos SQL.
>>
>> O PgQuery e PgSQL estão com as configurações padrão do componte e algumas
>> consultas fazem update insert e delete, mas a maioria apenas select.
>>
>> No Módulo da Central de Operações tem umas 300 querys e é onde dá
>> para se notar que o PgDAC diminuiu muito a performance em relação aos
>> componentes BDE.
>>
>> Esse monitor de captura de comandos é habilitado na PgQuery?
>>
>>
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] [off topic] PgDAC

[izaque Maciel]

Talvez, mesmo que dê mais trabalho, uma opção poderia ser o DBExpress, com
o Drive da Devart.


Em 11 de julho de 2013 11:53, Carlos Antônio Pereira (VidaUTI) <
carlosanto...@utivida.com.br> escreveu:

>   *From:* Douglas Fabiano Specht 
>  *Sent:* Thursday, July 11, 2013 8:30 AM
> *To:* Comunidade PostgreSQL Brasileira
> *Subject:* Re: [pgbr-geral] [off topic] PgDAC
>
>
>
>
> Em 11 de julho de 2013 00:19, Carlos Antônio Pereira (VidaUTI) <
> carlosanto...@utivida.com.br> escreveu:
>
>>   Boa noite, senhores.
>>
>>  Estou fazendo a migração de um sistema
>> de Delphi 5 para Delphi 6
>>  e mudando os componentes de conexão TQuery para TPgQuery
>>
>> que faz parte do componente PgDAC da Devart.
>>
>>  Os componentes PgDAC acabam com a camada BDE e ODBC.
>>  Sendo assim, deveria apresentar perfomance bem melhor já
>>  que serão duas camadas a menos para acessar os dados
>> .
>>
>>  O problema é que essa conexão PgDAC que deveria ser muito mais
>>  rápida está muito mais lenta.  Como estes componentes PgDAC
>>  tem muitas propriedades, imagino que isso seja alguma configuração.
>>
>>  Estou mudando o servidor também. Essa nova configuração está sendo
>>  montanda em um PowerEdge T320 com 16 Gb de RAM e HDs SAS de
>>  600 gb RAID 1,  com o PostgreSQL 9.2.
>>
>>  Alguém que usa esse componente pode me ajudar?
>>
>>  Att Carlos
>>
>>
>>
>>
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>>
>
> Bom dia Carlos,
>
> fizemos isso no ano passado em nossa aplicação, mas devido a estrutura de
> nossa aplicação e banco, não ganhamos muito em performance.
> Ganhamos sim em independência de Plataforma, de banco e na facil
> manutenção.
> por acaso vcs nao deixaram o monitor de captura de comandos sql sempre
> ativo?
>
>
> --
>
> Douglas Fabiano Specht
>
> --
>
> Bom dia, Douglas. Antes de tudo agradeço sua resposta.
> Então, como os compontes PgDAC são vastos em propriedades,
> ainda não me aprofundei em tudo.
>
>  Eu já tinha feito um teste com os componentes Zeos mas como
> este já não é atualizado há bastante tempo, resolvi investir no
> PgDAC que está em constante evolução.
>
> Também bolei uma forma bem prática de substituir os componentes
> através da edição do arquivo .dfm e com Replace fazer a troca das classes,
> o que aumenta minha produtividade na conversão.
>
> Os componentes TQuery (BDE) foram migrados para TPgQuery e TPgSQL.
> Não consegui rodar comandos em bloco pelo TPgQuery.
> Assim, Alguns scripts são rodados em TPgSQL que permite essa execução
> de blocos de comandos SQL.
>
> O PgQuery e PgSQL estão com as configurações padrão do componte e algumas
> consultas fazem update insert e delete, mas a maioria apenas select.
>
> No Módulo da Central de Operações tem umas 300 querys e é onde dá
> para se notar que o PgDAC diminuiu muito a performance em relação aos
> componentes BDE.
>
> Esse monitor de captura de comandos é habilitado na PgQuery?
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] [off topic] PgDAC

[VidaUTI]

From: Douglas Fabiano Specht 
Sent: Thursday, July 11, 2013 8:30 AM
To: Comunidade PostgreSQL Brasileira 
Subject: Re: [pgbr-geral] [off topic] PgDAC





Em 11 de julho de 2013 00:19, Carlos Antônio Pereira (VidaUTI) 
 escreveu:

  Boa noite, senhores.
  Estou fazendo a migração de um sistema de Delphi 5 para Delphi 6
  e mudando os componentes de conexão TQuery para TPgQuery
  que faz parte do componente PgDAC da Devart.
  Os componentes PgDAC acabam com a camada BDE e ODBC.
  Sendo assim, deveria apresentar perfomance bem melhor já
  que serão duas camadas a menos para acessar os dados.
  O problema é que essa conexão PgDAC que deveria ser muito mais 
  rápida está muito mais lenta.  Como estes componentes PgDAC
  tem muitas propriedades, imagino que isso seja alguma configuração.
  Estou mudando o servidor também. Essa nova configuração está sendo
  montanda em um PowerEdge T320 com 16 Gb de RAM e HDs SAS de 
  600 gb RAID 1,  com o PostgreSQL 9.2. 
  Alguém que usa esse componente pode me ajudar?
  Att Carlos   

  ___
  pgbr-geral mailing list
  pgbr-geral@listas.postgresql.org.br
  https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral





Bom dia Carlos,

fizemos isso no ano passado em nossa aplicação, mas devido a estrutura de nossa 
aplicação e banco, não ganhamos muito em performance.
Ganhamos sim em independência de Plataforma, de banco e na facil manutenção.
por acaso vcs nao deixaram o monitor de captura de comandos sql sempre ativo?


-- 


Douglas Fabiano Specht





Bom dia, Douglas. Antes de tudo agradeço sua resposta.
Então, como os compontes PgDAC são vastos em propriedades,
ainda não me aprofundei em tudo.

Eu já tinha feito um teste com os componentes Zeos mas como
este já não é atualizado há bastante tempo, resolvi investir no
PgDAC que está em constante evolução.

Também bolei uma forma bem prática de substituir os componentes
através da edição do arquivo .dfm e com Replace fazer a troca das classes,
o que aumenta minha produtividade na conversão.

Os componentes TQuery (BDE) foram migrados para TPgQuery e TPgSQL.
Não consegui rodar comandos em bloco pelo TPgQuery. 
Assim, Alguns scripts são rodados em TPgSQL que permite essa execução
de blocos de comandos SQL.

O PgQuery e PgSQL estão com as configurações padrão do componte e algumas
consultas fazem update insert e delete, mas a maioria apenas select.

No Módulo da Central de Operações tem umas 300 querys e é onde dá 
para se notar que o PgDAC diminuiu muito a performance em relação aos 
componentes BDE.

Esse monitor de captura de comandos é habilitado na PgQuery? 
 ___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] (sem assunto)

[Bruno Silva]

2013/7/11 Paulo Bastos 

> Em um servidor tenho vários bancos dentro de um unico cluster. Como
> proceder
> para fazer que os objetos do banco só possam ser consultados?
>

Você pode:
1 - Criar um usuário e dar permissão a ele somente de SELECT
2 - Criar um grupo com permissão somente de SELECT e atribuir os usuário a
ele.

Nos dois casos, usando REVOKE e GRANT[1]

[1] http://www.postgresql.org/docs/9.0/static/sql-grant.html

Bruno E. A. Silva.
Analista de Sistemas.
Bacharel em Sistemas de Informação
Pós-graduando em Gerência de Projetos
Certified Scrum Master
LPIC-1
SCJP, SE 6
Novell CLA / DCTS ECR
DBA Postgres
---
“A caixa dizia: Requer MS Windows ou superior. Então instalei Linux.” -
Sábio Desconhecido
"Alguns prestam serviço/consultoria de Qualidade, os outros vendem licença!"
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Permissões e Restrições de acesso a banco

[Paulo Bastos]

Senhores(as),
 
executei o comando 
 
REVOKE ALL PRIVILEGES ON SCHEMA ap FROM cpdsocic_group - Este funciona. Porem teria que tirar a permissão esquema por esquema. 
Poderia executar um script. Porem tenho vários esquemas com várias tabelas e vários bancos.
Tentei
 
REVOKE ALL PRIVILEGES ON DATABASE socic_ponto FROM cpdsocic_group; - Executou sem problemas. POrem continuo tendo acesso
as tabelas deste esquema.
 
Tentei
 
REVOKE ALL PRIVILEGES ON DATABASE socic_ponto FROM cpdsocic; - Executou também. POrem continuo tendo acesso as tabelas. Estou checando pelo
pg_admin, utilizando o usuário cpdsocic que faz parte do grupo cpdsocic_group.
 
Atenciosamente
 
Paulo Bastos
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] RES: [off topic] PgDAC

[jpaulorieg]

Em 11 de julho de 2013 00:19, Carlos Antônio Pereira (VidaUTI)
mailto:carlosanto...@utivida.com.br> >
escreveu:

Boa noite, senhores.

 

Estou fazendo a migração de um sistema 

de Delphi 5 para Delphi 6

e mudando os componentes de conexão TQuery para TPgQuery

 

que faz parte do componente PgDAC da Devart.

 

Os componentes PgDAC acabam com a camada BDE e ODBC.

Sendo assim, deveria apresentar perfomance bem melhor já

que serão duas camadas a menos para acessar os dados

.

 

O problema é que essa conexão PgDAC que deveria ser muito mais 

rápida está muito mais lenta.  Como estes componentes PgDAC

tem muitas propriedades, imagino que isso seja alguma configuração.

-
Não  utilizo o pgDAC para conexão com o sitema Delphi(xe) mas eu consigo
unir independência e performance com o componente ZEOS.

Ela tem funcionado super bem até a versão 9.0. Nas versões 9.1 ou superiores
estou com problemas apenas na gravação de arquivos bytea pois a biblioteca
oferecida pelo componente ainda não foi atualizada.
-

 

Estou mudando o servidor também. Essa nova configuração está sendo

montanda em um PowerEdge T320 com 16 Gb de RAM e HDs SAS de 

600 gb RAID 1,  com o PostgreSQL 9.2. 

--
Considere uma elevação da performance do SGBD se vc separar o pg_xlog em
outro array de discos SAS
--

 

Alguém que usa esse componente pode me ajudar?

 

Att Carlos   

 

 

 

 

Bom dia Carlos,

 

fizemos isso no ano passado em nossa aplicação, mas devido a estrutura de
nossa aplicação e banco, não ganhamos muito em performance.

Ganhamos sim em independência de Plataforma, de banco e na facil manutenção.

por acaso vcs nao deixaram o monitor de captura de comandos sql sempre
ativo?

 

-- 

Douglas Fabiano Specht

 

 

 

 

Att. Rieg

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Permissões e Restrições de acesso a banco

[Claudio Bezerra Leopoldino]

Altere a senha do grupo e não a dê para os outros. 

Crie novo grupo e dê permissão apenas de leitura nas tabelas e distribua a 
senha para os usuários. Abaixo, um post relacionado:
http://postgresqlbr.blogspot.com.br/2012/07/gere-automaticamente-seus-comandos.html

Cordialmente,

Cláudio Leopoldino

postgresqlbr.blogspot.com/
=



 De: Paulo Bastos 
Para: pgbr-geral@listas.postgresql.org.br 
Enviadas: Quinta-feira, 11 de Julho de 2013 9:26
Assunto: [pgbr-geral] Permissões e Restrições de acesso a banco
 


 
Desculpem,
 
enviei o email anterior e esqueci de colocar o assunto.
 
Senhores(as),
 
Em um servidor tenho vários bancos dentro de um unico cluster. Como proceder
para fazer que os objetos do banco só possam ser consultados?
 
Todas as tabelas estão associadas a um unico grupo.
 
Antecipadamente agradeço a ajuda.
 
Paulo Bastos
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Permissões e Restrições de acesso a banco

[Paulo Bastos]

 
Desculpem,
 
enviei o email anterior e esqueci de colocar o assunto.
 

Senhores(as),
 
Em um servidor tenho vários bancos dentro de um unico cluster. Como proceder
para fazer que os objetos do banco só possam ser consultados?
 
Todas as tabelas estão associadas a um unico grupo.
 
Antecipadamente agradeço a ajuda.
 
Paulo Bastos

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] (sem assunto)

[Paulo Bastos]

Senhores(as),
 
Em um servidor tenho vários bancos dentro de um unico cluster. Como proceder
para fazer que os objetos do banco só possam ser consultados?
 
Todas as tabelas estão associadas a um unico grupo.
 
Antecipadamente agradeço a ajuda.
 
Paulo Bastos
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] [off topic] PgDAC

[Douglas Fabiano Specht]

Em 11 de julho de 2013 00:19, Carlos Antônio Pereira (VidaUTI) <
carlosanto...@utivida.com.br> escreveu:

>   Boa noite, senhores.
>
>  Estou fazendo a migração de um sistema
> de Delphi 5 para Delphi 6
>  e mudando os componentes de conexão TQuery para TPgQuery
>
> que faz parte do componente PgDAC da Devart.
>
>  Os componentes PgDAC acabam com a camada BDE e ODBC.
>  Sendo assim, deveria apresentar perfomance bem melhor já
>  que serão duas camadas a menos para acessar os dados
> .
>
>  O problema é que essa conexão PgDAC que deveria ser muito mais
>  rápida está muito mais lenta.  Como estes componentes PgDAC
>  tem muitas propriedades, imagino que isso seja alguma configuração.
>
>  Estou mudando o servidor também. Essa nova configuração está sendo
>  montanda em um PowerEdge T320 com 16 Gb de RAM e HDs SAS de
>  600 gb RAID 1,  com o PostgreSQL 9.2.
>
>  Alguém que usa esse componente pode me ajudar?
>
>  Att Carlos
>
>
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>

Bom dia Carlos,

fizemos isso no ano passado em nossa aplicação, mas devido a estrutura de
nossa aplicação e banco, não ganhamos muito em performance.
Ganhamos sim em independência de Plataforma, de banco e na facil manutenção.
por acaso vcs nao deixaram o monitor de captura de comandos sql sempre
ativo?


-- 

Douglas Fabiano Specht
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral