[pgbr-geral] ALGUÉM JA VIU O SLONY FUNCIONAR , POR FAVOR ME AJUDE , COMIGO NAO FUNCIONA DE JEITO NENHUM

[neilton]

Amigos da Comunidade Utilizo o Postgresql  Versão  8.2  (WINDOWS XP)  e estou 
preso a um problea a meses

 Lá vai 
os Procedimentos

1) CRIACAO DO ARQUIVO  MASTER.CONF (cluster_name='Cl_teste'  
conn_info='host=localhost port=5432  dbname=master   user=postgres 
password=1234')
2) CRIACAO DO ARQUIVO  SLAVE.CONF (cluster_name='Cl_teste'  
conn_info='host=localhost port=5432  dbname=slave   user=postgres 
password=1234')
3) INSTALACAO DO SLONY COM SERVICO (slon -regservice Slony-I)
4) INSTALACAO DO ENGINE (slon -addengine Slony-I C:\slony\master.conf 
5) INSTALACAO DO ENGINE (slon -addengine Slony-I C:\slony\slave.conf)
6) DEFINICAO DO PATH DO SLONY ( Utilizando A  opção "options" c:\program 
files\postgresql\8.2\share)

7)  Agora Vem o problema : Na hora de criar o Cluster na opção  "NEW CLUSTER 
SLONY" ele desabilita o botão  "OK" e e coloca a seguinte mensagem  na janela 
" slony-I creation scripts not available; only joining possible"

Na minha tradução : "SCRIPT DE CRIACAO NAO DISPONIVEL, SOMENTE JUNCAO  É 
POSSÍVEL

 então nao consigo utilizar o slony

 ALGUÉM JA VIU O SLONY FUNCIONAR, por favor que script de criação ele ta 
reclamando?___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Não repedir dados do campo...

[Joao Cosme de Oliveira Junior]

Só para fechar entao.Se tiverers  varios atributos null  em uma relacao provavelmente o modelo esta furado :)Pronto!!João Cosme de Oliveira Júnior

Seja inteligente, use Software-livre!!!
LPI Certified
LPI000185554
Em 21/10/2009 às 22:06 horas, pgbr-geral@listas.postgresql.org.br escreveu:Olá,O Léo é um dos nossos gurus. A gente sempre aprende com ele, eu que o diga :)Um comentário. As vezes é muito mais fácil definirmos um campo como null do que modificar o modelo, porém la na frente veremos o que isso pode nos atrapalhar. Tenho alguns exemplos disso. Qualquer coisa eu posto aqui depois.
2009/10/21 Nilson Chagas 
Puxa nunca pensei que de uma pergunta como esta poderia aprender tanto.Valew, depois da sua explicação me deu até uma luz de como contornar de tal forma que não exista campos nulos.

2009/10/21 Leonardo Cezar 

2009/10/21 Joao Cosme de Oliveira Junior 
>
> Só para complementar .
> Null significa indeterminado ou não se aplica 

Só pra complementar++, ao utilizar NULL você estará assumindo
armazenar valores fora do domínio daquela coluna e portanto não
conseguirá armazenar requisitos sequer para alcançar 1FN
(desconsiderando as controvérsias).

Resultado disso são anomalias (tratamento especial) com agregação,
agrupameto, concatenação, ordenação, *ção.

Devido a falta de tipos nulos (aplicáveis e não-aplicáveis) no
SQL-ANSI torna-se impossível manter um modelo de dados consistente
utilizando atributos que permitam nulos.

De preferência por normalizar essa relação, por exemplo:

PESSOA { #CPF, NOME, PROFISSAO }

O atributo PROFISSAO pode ser "Nulo, mas aplicável", então:

PESSOA { #CPF, NOME }                            -- Tabela de pessoas
PROFISSAO { #CBO, TITULO, TIPO, ATIVO } -- Tabela de profissões
segundo ministério do trabalho;
OCUPACAO {#CPF, #CBO, DESDE, ... }        -- Tabela de profissões de uma PESSOA;

De acordo com o modelo acima, o atributo PROFISSAO só seria preenchido
quando uma PESSOA de fato possuir uma ocupação.

Desta forma eliminamos os NULLs da variável de relação PESSOA ->
PROFISSAO e obecedemos a 1FN.

Abraço!

-Leo
--
Leonardo Cezar
http://www.aslid.org.br
http://postgreslogia.wordpress.com
http://www.dextra.com.br/postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
-- []sNilson Chagas - Ubuntu User 25794---Visite: http://www.avozdoevangelho.com.br -> Peça gratuitamente um curso Bíblico

Twitter: avozdoevangelhoTwitter: matrixspnethttp://www.amados.com.brhttp://bbnradio.org -> Ouça a rádio e faça gratuitamente um Curso Biblico On-Line


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[]s-- JotaCommhttp://jotacomm.wordpress.com





"Esta mensagem do SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), empresa pública federal regida pelo disposto na Lei Federal nº 5.615, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco."

"This message from SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) -- a government company established under Brazilian law (5.615/70) -- is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure."
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Não repedir dados do campo...

[JotaComm]

Olá,

O Léo é um dos nossos gurus. A gente sempre aprende com ele, eu que o diga
:)

Um comentário. As vezes é muito mais fácil definirmos um campo como null do
que modificar o modelo, porém la na frente veremos o que isso pode nos
atrapalhar. Tenho alguns exemplos disso. Qualquer coisa eu posto aqui
depois.

2009/10/21 Nilson Chagas 

> Puxa nunca pensei que de uma pergunta como esta poderia aprender tanto.
>
>
> Valew, depois da sua explicação me deu até uma luz de como contornar de tal
> forma que não exista campos nulos.
>
>
> 2009/10/21 Leonardo Cezar 
>
>> 2009/10/21 Joao Cosme de Oliveira Junior 
>>
>> >
>> > Só para complementar .
>> > Null significa indeterminado ou não se aplica 
>>
>> Só pra complementar++, ao utilizar NULL você estará assumindo
>> armazenar valores fora do domínio daquela coluna e portanto não
>> conseguirá armazenar requisitos sequer para alcançar 1FN
>> (desconsiderando as controvérsias).
>>
>> Resultado disso são anomalias (tratamento especial) com agregação,
>> agrupameto, concatenação, ordenação, *ção.
>>
>> Devido a falta de tipos nulos (aplicáveis e não-aplicáveis) no
>> SQL-ANSI torna-se impossível manter um modelo de dados consistente
>> utilizando atributos que permitam nulos.
>>
>> De preferência por normalizar essa relação, por exemplo:
>>
>> PESSOA { #CPF, NOME, PROFISSAO }
>>
>> O atributo PROFISSAO pode ser "Nulo, mas aplicável", então:
>>
>> PESSOA { #CPF, NOME }-- Tabela de pessoas
>> PROFISSAO { #CBO, TITULO, TIPO, ATIVO } -- Tabela de profissões
>> segundo ministério do trabalho;
>> OCUPACAO {#CPF, #CBO, DESDE, ... }-- Tabela de profissões de uma
>> PESSOA;
>>
>> De acordo com o modelo acima, o atributo PROFISSAO só seria preenchido
>> quando uma PESSOA de fato possuir uma ocupação.
>>
>> Desta forma eliminamos os NULLs da variável de relação PESSOA ->
>> PROFISSAO e obecedemos a 1FN.
>>
>> Abraço!
>>
>> -Leo
>> --
>> Leonardo Cezar
>> http://www.aslid.org.br
>> http://postgreslogia.wordpress.com
>> http://www.dextra.com.br/postgres
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>
>
>
> --
> []s
> Nilson Chagas - Ubuntu User 25794
> ---
> Visite:
> http://www.avozdoevangelho.com.br -> Peça gratuitamente um curso Bíblico
>
> Twitter: avozdoevangelho
> Twitter: matrixspnet
>
> http://www.amados.com.br
> http://bbnradio.org -> Ouça a rádio e faça gratuitamente um Curso Biblico
> On-Line
>
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>

[]s
-- 
JotaComm
http://jotacomm.wordpress.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Não repedir dados do campo...

[JotaComm]

Olá,

Para completar o que o Osvaldo apresentou também pode-se alterar o parâmetro
transform_null_equals do postgresql.conf.

2009/10/21 Osvaldo Kussama 

> 2009/10/21 Joao Cosme de Oliveira Junior 
> >
> > Só para complementar .
> > Null significa indeterminado ou não se aplica 
> >
> > Por exemplo: o caboclo vai preencher um ficha e tem lá : número de
> gestações : coloque null , porque não se aplica!
> > Em outro caso pode ser indeterminado. Um exemplo bem tosco... em um campo
> idade:
> >
> > Então null não vai garantir unicidade, porque pode ser qualquer valor
> indeterminado. Por exemplo um campo null em um registro não tenho como dizer
> que é igual a um campo null em outro registro, já que são indeterminados!!
>
> Só para lembrar:
> O PostgreSQL possui a comparação IS [NOT] DISTINCT FROM que trata
> NULLs como sendo "iguais":
>
> bdteste=# SELECT NULL  IS NOT DISTINCT FROM  NULL;
>  ?column?
> --
>  t
> (1 registro)
>
> bdteste=# SELECT NULL  IS DISTINCT FROM  NULL;
>  ?column?
> --
>  f
> (1 registro)
>
> ENQUANTO
>
> bdteste=# SELECT NULL = NULL;
>  ?column?
> --
>  (null)
> (1 registro)
>
>
> >
> > Loucura Loucura !!!
> >
> > Abraços!!!
> >
> >
> >
> > João Cosme de Oliveira Júnior
> >
> > Seja inteligente, use Software-livre!!!
> > LPI Certified
> > LPI000185554
> >
> >
> > Em 21/10/2009 às 15:13 horas, pgbr-ge...@listas.postgresql.org.brescreveu:
> >
> > Muito obrigado, vou estar assim que chegar em casa.
> >
> > 2009/10/21 Osvaldo Kussama 
> >>
> >> 2009/10/21 Nilson Chagas :
> >> > Pessoal, vou fazer uma pergunta, creio eu de pura ignorancia, mas não
> sei
> >> > nem como procurar isto.
> >> >
> >> >
> >> > Tenho um campo na tabela que deve ser unico, salvo se ele estiver
> nulo, não
> >> > testei mas até onde eu sei indices unicos não permitem duplicar campos
> >> > nulos.
> >> >
> >> > Alguém pode me esclarecer isto??
> >> >
> >>
> >>
> >> Creio que é possível inserir vários registros que tenham o campo do
> índice NULL.
> >>
> >> bdteste=# CREATE TEMP TABLE foo(x int);
> >> CREATE TABLE
> >> bdteste=# CREATE UNIQUE INDEX id_x ON foo(x);
> >> CREATE INDEX
> >> bdteste=# INSERT INTO foo VALUES (0);
> >> INSERT 0 1
> >> bdteste=# INSERT INTO foo VALUES (1);
> >> INSERT 0 1
> >> bdteste=# INSERT INTO foo VALUES (1);
> >> ERRO:  duplicar valor da chave viola a restrição de unicidade "id_x"
> >> bdteste=# INSERT INTO foo VALUES (null);
> >> INSERT 0 1
> >> bdteste=# INSERT INTO foo VALUES (null);
> >> INSERT 0 1
> >> bdteste=# INSERT INTO foo VALUES (null);
> >> INSERT 0 1
> >>
> >> bdteste=# \pset null '(null)'
> >> Exibição nula é "(null)".
> >> bdteste=# SELECT * FROM foo;
> >>   x
> >> 
> >>  0
> >>  1
> >>  (null)
> >>  (null)
> >>  (null)
> >> (5 registros)
> >>
>
>
> Osvaldo
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>


[]s
-- 
JotaComm
http://jotacomm.wordpress.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] O que faço ?

[Tiago Adami]

Já passei por este problema várias vezes. Infelizmente - ou felizmente,
depende do ponto de vista - o PostgreSQL não armazena todo o banco de dados
em um único arquivo (a exemplo do Sybase, Firebird, Oracle). Tudo fica
espalhado no disco, certamente na pasta "data" (ou a pasta do cluster).

A empresa onde trabalho comercializa um ERP onde é utilizado somente o
PostgreSQL, e para evitar maiores problemas, deixamos claro no contrato de
utilização do software que *não somos responsáveis pelo backup*, mais
exatamente sobre o armazenamento dos mesmos. Indicamos as boas maneiras, mas
mesmo assim a maioria dos clientes só aprende quando acontece algum
desastre.

As únicas maneiras de recuperar os dados são através da pasta *data* ou de
arquivos de backup. Fora isso, acredito que não exista outra maneira - já
que você não mencionou um espelhamento ou backup transacional.

Quanto ao seu problema agora: o recovery que você menciona foi realizado por
algum programa para recuperar arquivos excluidos do disco? Não quero te
desanimar, mas se os arquivos foram eliminados e algum arquivo gravado
posteriormente substituiu o setor do disco onde estava o banco de dados, não
haverá solução.

-- 
Tiago J. Adami
http://www.adamiworks.com




2009/10/21 George 

>  gente, boa noite !
>
> Estou enfretando um problemamuito grave !
>
> Quando comcei usar o postgresql a uns dois anos atrás para migrar meus
> dados, fiquei muito satisfeito pois comecei a ter um diferencial que é
> umbanco de dados estável e principalmete free em suma meus clientes não
> tiveram custos quanto a licenças e deu um boom no meu produto e negócio
> cresceu tanto que comecou a incomodar muita gente no meu ramo.
>
> Hoje de manha um cliente me ligou dizendo parou tudo.fui até lá e vi
> que desapareceu 90% dos arquivos da pasta data osoutros 10 não sumiu devido
> os zrquivos estarem em uso, ai vdcs pergunto cadê o backup  !!  realizo um
> backup automatico a 4 horas e sempre fica os ultimos 7 dias mas para minha
> surpresa tb não estava lá, pois o hd que gravavsa foi todo deletado.
> Imaginei éo antivirus avast, fui ver olog e nada, vi olog de evebtos e nada
> e assim vai, me descabelei e peguei um recover na internet até ai blz..até
> que consegui achar a pasta dos dados, tentei recuperar e recuperou mas não
> abre de jeito nehum o banco de dados pois dá erro de uma tabela do
> pg_catalog não existir..procurei pelo backups e incrivel não estava lá e
> pesquisei na internet sobre e soube que os arquivos movidos não estavam lá.
>
> Estou desde as 10 da manha até nesta hora e comecei a ser cobrado por isso,
> mas pasmem..eles tem um TI na empresa e eram responsáveis por tudo isso.
>
> Não quero ser precipitado em acusar ou indicar um culpado,
>
> preciso da ajuda de vcs para achar a solução...consegui um backup que eu
> tinha deles mas é de 2 meses atrás.
>
> Tenho todos os dados nestes arquivos que recuperei pelo recovery...alguém
> tem uma luz..por favor ! estou desde a 9 da manha até agora procurando uma
> solução.
>
>
> Obrigado
>
> PS. Todos os dias aprendemos, e por este motivo aprendi que tenho que
> cuidar cada vez mais dos meus produtos para não acontecer o que ocorreu
> hoje.
>
>
>
>
>
> ___
> 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] O que faço ?

[George]

Ai que tah , existe uma rotina que grava em outra partição e posteriormente a 
TI grava em mídia,mas ao perguntar sobre isso eles diseeram que não fazziam o 
bakup a algum tempo
  - Original Message - 
  From: George Silva 
  To: Comunidade PostgreSQL Brasileira 
  Sent: Wednesday, October 21, 2009 6:55 PM
  Subject: Re: [pgbr-geral] O que faço ?


  Você não transporta os arquivos de backup para uma outra (localidade) 
máquina/tipo de armazenamento?

  George Silva


  2009/10/21 George 

gente, boa noite !

Estou enfretando um problemamuito grave !

Quando comcei usar o postgresql a uns dois anos atrás para migrar meus 
dados, fiquei muito satisfeito pois comecei a ter um diferencial que é umbanco 
de dados estável e principalmete free em suma meus clientes não tiveram custos 
quanto a licenças e deu um boom no meu produto e negócio cresceu tanto que 
comecou a incomodar muita gente no meu ramo.

Hoje de manha um cliente me ligou dizendo parou tudo.fui até lá e vi 
que desapareceu 90% dos arquivos da pasta data osoutros 10 não sumiu devido os 
zrquivos estarem em uso, ai vdcs pergunto cadê o backup  !!  realizo um backup 
automatico a 4 horas e sempre fica os ultimos 7 dias mas para minha surpresa tb 
não estava lá, pois o hd que gravavsa foi todo deletado. Imaginei éo antivirus 
avast, fui ver olog e nada, vi olog de evebtos e nada e assim vai, me 
descabelei e peguei um recover na internet até ai blz..até que consegui achar a 
pasta dos dados, tentei recuperar e recuperou mas não abre de jeito nehum o 
banco de dados pois dá erro de uma tabela do pg_catalog não existir..procurei 
pelo backups e incrivel não estava lá e pesquisei na internet sobre e soube que 
os arquivos movidos não estavam lá.

Estou desde as 10 da manha até nesta hora e comecei a ser cobrado por isso, 
mas pasmem..eles tem um TI na empresa e eram responsáveis por tudo isso.

Não quero ser precipitado em acusar ou indicar um culpado,

preciso da ajuda de vcs para achar a solução...consegui um backup que eu 
tinha deles mas é de 2 meses atrás. 

Tenho todos os dados nestes arquivos que recuperei pelo recovery...alguém 
tem uma luz..por favor ! estou desde a 9 da manha até agora procurando uma 
solução.


Obrigado

PS. Todos os dias aprendemos, e por este motivo aprendi que tenho que 
cuidar cada vez mais dos meus produtos para não acontecer o que ocorreu hoje.





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





  -- 
  George R. C. Silva

  Desenvolvimento em GIS
  www.sextantegeo2.blogspot.com



--


  ___
  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] O que faço ?

[George Silva]

Você não transporta os arquivos de backup para uma outra (localidade)
máquina/tipo de armazenamento?

George Silva

2009/10/21 George 

>  gente, boa noite !
>
> Estou enfretando um problemamuito grave !
>
> Quando comcei usar o postgresql a uns dois anos atrás para migrar meus
> dados, fiquei muito satisfeito pois comecei a ter um diferencial que é
> umbanco de dados estável e principalmete free em suma meus clientes não
> tiveram custos quanto a licenças e deu um boom no meu produto e negócio
> cresceu tanto que comecou a incomodar muita gente no meu ramo.
>
> Hoje de manha um cliente me ligou dizendo parou tudo.fui até lá e vi
> que desapareceu 90% dos arquivos da pasta data osoutros 10 não sumiu devido
> os zrquivos estarem em uso, ai vdcs pergunto cadê o backup  !!  realizo um
> backup automatico a 4 horas e sempre fica os ultimos 7 dias mas para minha
> surpresa tb não estava lá, pois o hd que gravavsa foi todo deletado.
> Imaginei éo antivirus avast, fui ver olog e nada, vi olog de evebtos e nada
> e assim vai, me descabelei e peguei um recover na internet até ai blz..até
> que consegui achar a pasta dos dados, tentei recuperar e recuperou mas não
> abre de jeito nehum o banco de dados pois dá erro de uma tabela do
> pg_catalog não existir..procurei pelo backups e incrivel não estava lá e
> pesquisei na internet sobre e soube que os arquivos movidos não estavam lá.
>
> Estou desde as 10 da manha até nesta hora e comecei a ser cobrado por isso,
> mas pasmem..eles tem um TI na empresa e eram responsáveis por tudo isso.
>
> Não quero ser precipitado em acusar ou indicar um culpado,
>
> preciso da ajuda de vcs para achar a solução...consegui um backup que eu
> tinha deles mas é de 2 meses atrás.
>
> Tenho todos os dados nestes arquivos que recuperei pelo recovery...alguém
> tem uma luz..por favor ! estou desde a 9 da manha até agora procurando uma
> solução.
>
>
> Obrigado
>
> PS. Todos os dias aprendemos, e por este motivo aprendi que tenho que
> cuidar cada vez mais dos meus produtos para não acontecer o que ocorreu
> hoje.
>
>
>
>
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>


-- 
George R. C. Silva

Desenvolvimento em GIS
www.sextantegeo2.blogspot.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] O que faço ?

[George]

gente, boa noite !

Estou enfretando um problemamuito grave !

Quando comcei usar o postgresql a uns dois anos atrás para migrar meus dados, 
fiquei muito satisfeito pois comecei a ter um diferencial que é umbanco de 
dados estável e principalmete free em suma meus clientes não tiveram custos 
quanto a licenças e deu um boom no meu produto e negócio cresceu tanto que 
comecou a incomodar muita gente no meu ramo.

Hoje de manha um cliente me ligou dizendo parou tudo.fui até lá e vi que 
desapareceu 90% dos arquivos da pasta data osoutros 10 não sumiu devido os 
zrquivos estarem em uso, ai vdcs pergunto cadê o backup  !!  realizo um backup 
automatico a 4 horas e sempre fica os ultimos 7 dias mas para minha surpresa tb 
não estava lá, pois o hd que gravavsa foi todo deletado. Imaginei éo antivirus 
avast, fui ver olog e nada, vi olog de evebtos e nada e assim vai, me 
descabelei e peguei um recover na internet até ai blz..até que consegui achar a 
pasta dos dados, tentei recuperar e recuperou mas não abre de jeito nehum o 
banco de dados pois dá erro de uma tabela do pg_catalog não existir..procurei 
pelo backups e incrivel não estava lá e pesquisei na internet sobre e soube que 
os arquivos movidos não estavam lá.

Estou desde as 10 da manha até nesta hora e comecei a ser cobrado por isso, mas 
pasmem..eles tem um TI na empresa e eram responsáveis por tudo isso.

Não quero ser precipitado em acusar ou indicar um culpado,

preciso da ajuda de vcs para achar a solução...consegui um backup que eu tinha 
deles mas é de 2 meses atrás. 

Tenho todos os dados nestes arquivos que recuperei pelo recovery...alguém tem 
uma luz..por favor ! estou desde a 9 da manha até agora procurando uma solução.


Obrigado

PS. Todos os dias aprendemos, e por este motivo aprendi que tenho que cuidar 
cada vez mais dos meus produtos para não acontecer o que ocorreu hoje.



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

Re: [pgbr-geral] Não repedir dados do campo...

[Osvaldo Kussama]

2009/10/21 Joao Cosme de Oliveira Junior 
>
> Só para complementar .
> Null significa indeterminado ou não se aplica 
>
> Por exemplo: o caboclo vai preencher um ficha e tem lá : número de gestações 
> : coloque null , porque não se aplica!
> Em outro caso pode ser indeterminado. Um exemplo bem tosco... em um campo 
> idade:
>
> Então null não vai garantir unicidade, porque pode ser qualquer valor 
> indeterminado. Por exemplo um campo null em um registro não tenho como dizer 
> que é igual a um campo null em outro registro, já que são indeterminados!!

Só para lembrar:
O PostgreSQL possui a comparação IS [NOT] DISTINCT FROM que trata
NULLs como sendo "iguais":

bdteste=# SELECT NULL  IS NOT DISTINCT FROM  NULL;
 ?column?
--
 t
(1 registro)

bdteste=# SELECT NULL  IS DISTINCT FROM  NULL;
 ?column?
--
 f
(1 registro)

ENQUANTO

bdteste=# SELECT NULL = NULL;
 ?column?
--
 (null)
(1 registro)


>
> Loucura Loucura !!!
>
> Abraços!!!
>
>
>
> João Cosme de Oliveira Júnior
>
> Seja inteligente, use Software-livre!!!
> LPI Certified
> LPI000185554
>
>
> Em 21/10/2009 às 15:13 horas, pgbr-geral@listas.postgresql.org.br escreveu:
>
> Muito obrigado, vou estar assim que chegar em casa.
>
> 2009/10/21 Osvaldo Kussama 
>>
>> 2009/10/21 Nilson Chagas :
>> > Pessoal, vou fazer uma pergunta, creio eu de pura ignorancia, mas não sei
>> > nem como procurar isto.
>> >
>> >
>> > Tenho um campo na tabela que deve ser unico, salvo se ele estiver nulo, não
>> > testei mas até onde eu sei indices unicos não permitem duplicar campos
>> > nulos.
>> >
>> > Alguém pode me esclarecer isto??
>> >
>>
>>
>> Creio que é possível inserir vários registros que tenham o campo do índice 
>> NULL.
>>
>> bdteste=# CREATE TEMP TABLE foo(x int);
>> CREATE TABLE
>> bdteste=# CREATE UNIQUE INDEX id_x ON foo(x);
>> CREATE INDEX
>> bdteste=# INSERT INTO foo VALUES (0);
>> INSERT 0 1
>> bdteste=# INSERT INTO foo VALUES (1);
>> INSERT 0 1
>> bdteste=# INSERT INTO foo VALUES (1);
>> ERRO:  duplicar valor da chave viola a restrição de unicidade "id_x"
>> bdteste=# INSERT INTO foo VALUES (null);
>> INSERT 0 1
>> bdteste=# INSERT INTO foo VALUES (null);
>> INSERT 0 1
>> bdteste=# INSERT INTO foo VALUES (null);
>> INSERT 0 1
>>
>> bdteste=# \pset null '(null)'
>> Exibição nula é "(null)".
>> bdteste=# SELECT * FROM foo;
>>   x
>> 
>>      0
>>      1
>>  (null)
>>  (null)
>>  (null)
>> (5 registros)
>>


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

[pgbr-geral] Transporte para o PGCon Brasil 2009

[Leonardo Cezar]

Mensagem encaminhada pelo Fábio:

Senhores e senhoritas, inauguramos uma nova página no site do PGCon
Brasil 2009 para ajudar os viajantes:

http://pgcon.postgresql.org.br/2009/transporte.php

Espero que isso ajude!!!

[]s
Fábio Telles
---
blog: http://www.midstorm.org/~telles/
e-mail / jabber: fabio.tel...@gmail.com
___
pgbr-dev mailing list
pgbr-...@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-dev

-- 
Leonardo Cezar
http://www.aslid.org.br
http://postgreslogia.wordpress.com
http://www.dextra.com.br/postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Não repedir dados do campo...

[Nilson Chagas]

Puxa nunca pensei que de uma pergunta como esta poderia aprender tanto.


Valew, depois da sua explicação me deu até uma luz de como contornar de tal
forma que não exista campos nulos.


2009/10/21 Leonardo Cezar 

> 2009/10/21 Joao Cosme de Oliveira Junior 
> >
> > Só para complementar .
> > Null significa indeterminado ou não se aplica 
>
> Só pra complementar++, ao utilizar NULL você estará assumindo
> armazenar valores fora do domínio daquela coluna e portanto não
> conseguirá armazenar requisitos sequer para alcançar 1FN
> (desconsiderando as controvérsias).
>
> Resultado disso são anomalias (tratamento especial) com agregação,
> agrupameto, concatenação, ordenação, *ção.
>
> Devido a falta de tipos nulos (aplicáveis e não-aplicáveis) no
> SQL-ANSI torna-se impossível manter um modelo de dados consistente
> utilizando atributos que permitam nulos.
>
> De preferência por normalizar essa relação, por exemplo:
>
> PESSOA { #CPF, NOME, PROFISSAO }
>
> O atributo PROFISSAO pode ser "Nulo, mas aplicável", então:
>
> PESSOA { #CPF, NOME }-- Tabela de pessoas
> PROFISSAO { #CBO, TITULO, TIPO, ATIVO } -- Tabela de profissões
> segundo ministério do trabalho;
> OCUPACAO {#CPF, #CBO, DESDE, ... }-- Tabela de profissões de uma
> PESSOA;
>
> De acordo com o modelo acima, o atributo PROFISSAO só seria preenchido
> quando uma PESSOA de fato possuir uma ocupação.
>
> Desta forma eliminamos os NULLs da variável de relação PESSOA ->
> PROFISSAO e obecedemos a 1FN.
>
> Abraço!
>
> -Leo
> --
> Leonardo Cezar
> http://www.aslid.org.br
> http://postgreslogia.wordpress.com
> http://www.dextra.com.br/postgres
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
[]s
Nilson Chagas - Ubuntu User 25794
---
Visite:
http://www.avozdoevangelho.com.br -> Peça gratuitamente um curso Bíblico

Twitter: avozdoevangelho
Twitter: matrixspnet

http://www.amados.com.br
http://bbnradio.org -> Ouça a rádio e faça gratuitamente um Curso Biblico
On-Line
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Não repedir dados do campo...

[Andre Fernandes]

Muito bom lembrares desse detalhe de modelagem, infelizmente poucos conhecem
os problemas de usar NULL. Ficou bem didático (quem me dera quando estudei
em banco de dados tivessem tido essa didática... Teria sido muito mais
simples :-))!

Abraços

2009/10/21 Leonardo Cezar 

> 2009/10/21 Joao Cosme de Oliveira Junior 
> >
> > Só para complementar .
> > Null significa indeterminado ou não se aplica 
>
> Só pra complementar++, ao utilizar NULL você estará assumindo
> armazenar valores fora do domínio daquela coluna e portanto não
> conseguirá armazenar requisitos sequer para alcançar 1FN
> (desconsiderando as controvérsias).
>
> Resultado disso são anomalias (tratamento especial) com agregação,
> agrupameto, concatenação, ordenação, *ção.
>
> Devido a falta de tipos nulos (aplicáveis e não-aplicáveis) no
> SQL-ANSI torna-se impossível manter um modelo de dados consistente
> utilizando atributos que permitam nulos.
>
> De preferência por normalizar essa relação, por exemplo:
>
> PESSOA { #CPF, NOME, PROFISSAO }
>
> O atributo PROFISSAO pode ser "Nulo, mas aplicável", então:
>
> PESSOA { #CPF, NOME }-- Tabela de pessoas
> PROFISSAO { #CBO, TITULO, TIPO, ATIVO } -- Tabela de profissões
> segundo ministério do trabalho;
> OCUPACAO {#CPF, #CBO, DESDE, ... }-- Tabela de profissões de uma
> PESSOA;
>
> De acordo com o modelo acima, o atributo PROFISSAO só seria preenchido
> quando uma PESSOA de fato possuir uma ocupação.
>
> Desta forma eliminamos os NULLs da variável de relação PESSOA ->
> PROFISSAO e obecedemos a 1FN.
>
> Abraço!
>
> -Leo
> --
> Leonardo Cezar
> http://www.aslid.org.br
> http://postgreslogia.wordpress.com
> http://www.dextra.com.br/postgres
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
André de Camargo Fernandes
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Não repedir dados do campo...

[Leonardo Cezar]

2009/10/21 Joao Cosme de Oliveira Junior 
>
> Só para complementar .
> Null significa indeterminado ou não se aplica 

Só pra complementar++, ao utilizar NULL você estará assumindo
armazenar valores fora do domínio daquela coluna e portanto não
conseguirá armazenar requisitos sequer para alcançar 1FN
(desconsiderando as controvérsias).

Resultado disso são anomalias (tratamento especial) com agregação,
agrupameto, concatenação, ordenação, *ção.

Devido a falta de tipos nulos (aplicáveis e não-aplicáveis) no
SQL-ANSI torna-se impossível manter um modelo de dados consistente
utilizando atributos que permitam nulos.

De preferência por normalizar essa relação, por exemplo:

PESSOA { #CPF, NOME, PROFISSAO }

O atributo PROFISSAO pode ser "Nulo, mas aplicável", então:

PESSOA { #CPF, NOME }-- Tabela de pessoas
PROFISSAO { #CBO, TITULO, TIPO, ATIVO } -- Tabela de profissões
segundo ministério do trabalho;
OCUPACAO {#CPF, #CBO, DESDE, ... }-- Tabela de profissões de uma PESSOA;

De acordo com o modelo acima, o atributo PROFISSAO só seria preenchido
quando uma PESSOA de fato possuir uma ocupação.

Desta forma eliminamos os NULLs da variável de relação PESSOA ->
PROFISSAO e obecedemos a 1FN.

Abraço!

-Leo
--
Leonardo Cezar
http://www.aslid.org.br
http://postgreslogia.wordpress.com
http://www.dextra.com.br/postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Não repedir dados do campo...

[Joao Cosme de Oliveira Junior]

Só para complementar .Null significa indeterminado ou não se aplica Por exemplo: o caboclo vai preencher um ficha e tem lá : número de gestações : coloque null , porque não se aplica!Em outro caso pode ser indeterminado. Um exemplo bem tosco... em um campo idade:Então null não vai garantir unicidade, porque pode ser qualquer valor indeterminado. Por exemplo um campo null em um registro não tenho como dizer que é igual a um campo null em outro registro, já que são indeterminados!!Loucura Loucura !!!Abraços!!!João Cosme de Oliveira Júnior

Seja inteligente, use Software-livre!!!
LPI Certified
LPI000185554
Em 21/10/2009 às 15:13 horas, pgbr-geral@listas.postgresql.org.br escreveu:Muito obrigado, vou estar assim que chegar em casa.2009/10/21 Osvaldo Kussama 
2009/10/21 Nilson Chagas :
> Pessoal, vou fazer uma pergunta, creio eu de pura ignorancia, mas não sei
> nem como procurar isto.
>
>
> Tenho um campo na tabela que deve ser unico, salvo se ele estiver nulo, não
> testei mas até onde eu sei indices unicos não permitem duplicar campos
> nulos.
>
> Alguém pode me esclarecer isto??
>


Creio que é possível inserir vários registros que tenham o campo do índice NULL.

bdteste=# CREATE TEMP TABLE foo(x int);
CREATE TABLE
bdteste=# CREATE UNIQUE INDEX id_x ON foo(x);
CREATE INDEX
bdteste=# INSERT INTO foo VALUES (0);
INSERT 0 1
bdteste=# INSERT INTO foo VALUES (1);
INSERT 0 1
bdteste=# INSERT INTO foo VALUES (1);
ERRO:  duplicar valor da chave viola a restrição de unicidade "id_x"
bdteste=# INSERT INTO foo VALUES (null);
INSERT 0 1
bdteste=# INSERT INTO foo VALUES (null);
INSERT 0 1
bdteste=# INSERT INTO foo VALUES (null);
INSERT 0 1

bdteste=# \pset null '(null)'
Exibição nula é "(null)".
bdteste=# SELECT * FROM foo;
   x

      0
      1
 (null)
 (null)
 (null)
(5 registros)

Osvaldo
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
-- []sNilson Chagas - Ubuntu User 25794---Visite: http://www.avozdoevangelho.com.br -> Peça gratuitamente um curso Bíblico
Twitter: avozdoevangelhoTwitter: matrixspnethttp://www.amados.com.brhttp://bbnradio.org -> Ouça a rádio e faça gratuitamente um Curso Biblico On-Line






"Esta mensagem do SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), empresa pública federal regida pelo disposto na Lei Federal nº 5.615, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco."

"This message from SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) -- a government company established under Brazilian law (5.615/70) -- is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure."
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Não repedir dados do campo...

[Nilson Chagas]

Muito obrigado, vou estar assim que chegar em casa.

2009/10/21 Osvaldo Kussama 

> 2009/10/21 Nilson Chagas :
> > Pessoal, vou fazer uma pergunta, creio eu de pura ignorancia, mas não sei
> > nem como procurar isto.
> >
> >
> > Tenho um campo na tabela que deve ser unico, salvo se ele estiver nulo,
> não
> > testei mas até onde eu sei indices unicos não permitem duplicar campos
> > nulos.
> >
> > Alguém pode me esclarecer isto??
> >
>
>
> Creio que é possível inserir vários registros que tenham o campo do índice
> NULL.
>
> bdteste=# CREATE TEMP TABLE foo(x int);
> CREATE TABLE
> bdteste=# CREATE UNIQUE INDEX id_x ON foo(x);
> CREATE INDEX
> bdteste=# INSERT INTO foo VALUES (0);
> INSERT 0 1
> bdteste=# INSERT INTO foo VALUES (1);
> INSERT 0 1
> bdteste=# INSERT INTO foo VALUES (1);
> ERRO:  duplicar valor da chave viola a restrição de unicidade "id_x"
> bdteste=# INSERT INTO foo VALUES (null);
> INSERT 0 1
> bdteste=# INSERT INTO foo VALUES (null);
> INSERT 0 1
> bdteste=# INSERT INTO foo VALUES (null);
> INSERT 0 1
>
> bdteste=# \pset null '(null)'
> Exibição nula é "(null)".
> bdteste=# SELECT * FROM foo;
>   x
> 
>  0
>  1
>  (null)
>  (null)
>  (null)
> (5 registros)
>
> Osvaldo
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
[]s
Nilson Chagas - Ubuntu User 25794
---
Visite:
http://www.avozdoevangelho.com.br -> Peça gratuitamente um curso Bíblico

Twitter: avozdoevangelho
Twitter: matrixspnet

http://www.amados.com.br
http://bbnradio.org -> Ouça a rádio e faça gratuitamente um Curso Biblico
On-Line
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Não repedir dados do campo...

[Osvaldo Kussama]

2009/10/21 Nilson Chagas :
> Pessoal, vou fazer uma pergunta, creio eu de pura ignorancia, mas não sei
> nem como procurar isto.
>
>
> Tenho um campo na tabela que deve ser unico, salvo se ele estiver nulo, não
> testei mas até onde eu sei indices unicos não permitem duplicar campos
> nulos.
>
> Alguém pode me esclarecer isto??
>


Creio que é possível inserir vários registros que tenham o campo do índice NULL.

bdteste=# CREATE TEMP TABLE foo(x int);
CREATE TABLE
bdteste=# CREATE UNIQUE INDEX id_x ON foo(x);
CREATE INDEX
bdteste=# INSERT INTO foo VALUES (0);
INSERT 0 1
bdteste=# INSERT INTO foo VALUES (1);
INSERT 0 1
bdteste=# INSERT INTO foo VALUES (1);
ERRO:  duplicar valor da chave viola a restrição de unicidade "id_x"
bdteste=# INSERT INTO foo VALUES (null);
INSERT 0 1
bdteste=# INSERT INTO foo VALUES (null);
INSERT 0 1
bdteste=# INSERT INTO foo VALUES (null);
INSERT 0 1

bdteste=# \pset null '(null)'
Exibição nula é "(null)".
bdteste=# SELECT * FROM foo;
   x

  0
  1
 (null)
 (null)
 (null)
(5 registros)

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

Re: [pgbr-geral] Não repedir dados do campo...

[Tiago Adami]

Crie um índice único na sua coluna, incluindo apenas o campo onde os dados
não podem se repetir - ou seja, criar um índice com o comando CREATE UNIQUE
INDEX [1].

[1] http://www.postgresql.org/docs/8.4/static/sql-createindex.html

--
Tiago J. Adami
http://www.adamiworks.com


2009/10/21 Nilson Chagas 

> Pessoal, vou fazer uma pergunta, creio eu de pura ignorancia, mas não sei
> nem como procurar isto.
>
>
> Tenho um campo na tabela que deve ser unico, salvo se ele estiver nulo, não
> testei mas até onde eu sei indices unicos não permitem duplicar campos
> nulos.
>
> Alguém pode me esclarecer isto??
>
> --
> []s
> Nilson Chagas - Ubuntu User 25794
> ---
> Visite:
> http://www.avozdoevangelho.com.br -> Peça gratuitamente um curso Bíblico
>
> Twitter: avozdoevangelho
> Twitter: matrixspnet
>
> http://www.amados.com.br
> http://bbnradio.org -> Ouça a rádio e faça gratuitamente um Curso Biblico
> On-Line
>
>
>
> ___
> 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] Não repedir dados do campo...

[Wellington]

Veja se pode lhe ajudar (
http://www.network-theory.co.uk/docs/postgresql/vol1/UniqueConstraints.html
)

Nilson Chagas wrote:
Pessoal, vou fazer uma pergunta, creio eu de pura
ignorancia, mas não sei nem como procurar isto.
  
  
Tenho um campo na tabela que deve ser unico, salvo se ele estiver nulo,
não testei mas até onde eu sei indices unicos não permitem duplicar
campos nulos.
  
Alguém pode me esclarecer isto??
  
-- 
[]s
Nilson Chagas - Ubuntu User 25794
---
Visite: 
  http://www.avozdoevangelho.com.br
-> Peça gratuitamente um curso Bíblico
  
Twitter: avozdoevangelho
Twitter: matrixspnet
  
  http://www.amados.com.br
  http://bbnradio.org
-> Ouça a rádio e faça gratuitamente um Curso Biblico On-Line
  
  
  

___
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] Não repedir dados do campo...

[Nilson Chagas]

Pessoal, vou fazer uma pergunta, creio eu de pura ignorancia, mas não sei
nem como procurar isto.


Tenho um campo na tabela que deve ser unico, salvo se ele estiver nulo, não
testei mas até onde eu sei indices unicos não permitem duplicar campos
nulos.

Alguém pode me esclarecer isto??

-- 
[]s
Nilson Chagas - Ubuntu User 25794
---
Visite:
http://www.avozdoevangelho.com.br -> Peça gratuitamente um curso Bíblico

Twitter: avozdoevangelho
Twitter: matrixspnet

http://www.amados.com.br
http://bbnradio.org -> Ouça a rádio e faça gratuitamente um Curso Biblico
On-Line
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] caixa alta

[Everson Barbosa]

Rodrigo,

   Só uma observação...o nome correto do bd é Postgres ou PostgreSQL e não
'postgre'.

Abc

Everson

2009/10/21 Osvaldo Kussama 

> 2009/10/21 Rodrigo Ibraim [PGOpen] :
> > Bom dia
> >
> > Sempre ouvi dizer que palavras reservadas do postgre, devem ser escritas
> em
> > caixa alta e objetos em caixa baixa. Sempre segui esta regra com meus
> sql's,
> > gostaria de saber se isso realmente é verdade e se sim, se ajuda no
> > desempenho da aplicação.
> >
>
>
> Veja:
>
> http://www.postgresql.org/docs/current/interactive/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS
>
> "A convention often used is to write key words in upper case and names
> in lower case"
>
> Como diz o manual é uma convenção (adotada por muita gente). Não creio
> que interfira no desempenho da aplicação, talvez de forma extremamente
> marginal na análise sintática do comando.
>
> Osvaldo
>
> PS. Apenas preste atenção ao identificador delimitado ou identificador
> entre aspas que passa a respeitar a caixa utilizada (case-sensitive)
> ___
> 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] problema com transação

[Euler Taveira de Oliveira]

engelnit escreveu:
> As rotinas rodam através da minha aplicação. Os erros são de execução de
> query, consultas e inserts, podendo ocorrer em qualquer tabela ou registro.
> Como eu disse, são eventuais, não repetitivos. Eu capturo
> esses sqls, e rodo no pgadim, eles executam sem problema. E se eu rodar
> novamente a rotina, com transação, nesse grupo de registros que deram erro,
> rodará normal, sem erro. Parece que esses erros só 
> ocorrem mesmo quando o volume de registro é grande.
> 
Sem um exemplo (mesmo mascarando os nomes das tabelas, campos e dados) fica
difícil prever o que está acontecendo. Cole aqui a transação e o erro
apresentado pelo PostgreSQL. É bom também informar o a versão do PostgreSQL, o
driver utilizado, e as configurações fora do padrão (sem comentário) que está
utilizando no postgresql.conf.


-- 
  Euler Taveira de Oliveira
  http://www.timbira.com/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] caixa alta

[Osvaldo Kussama]

2009/10/21 Rodrigo Ibraim [PGOpen] :
> Bom dia
>
> Sempre ouvi dizer que palavras reservadas do postgre, devem ser escritas em
> caixa alta e objetos em caixa baixa. Sempre segui esta regra com meus sql's,
> gostaria de saber se isso realmente é verdade e se sim, se ajuda no
> desempenho da aplicação.
>


Veja:
http://www.postgresql.org/docs/current/interactive/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS

"A convention often used is to write key words in upper case and names
in lower case"

Como diz o manual é uma convenção (adotada por muita gente). Não creio
que interfira no desempenho da aplicação, talvez de forma extremamente
marginal na análise sintática do comando.

Osvaldo

PS. Apenas preste atenção ao identificador delimitado ou identificador
entre aspas que passa a respeitar a caixa utilizada (case-sensitive)
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] caixa alta

[Euler Taveira de Oliveira]

Rodrigo Ibraim [PGOpen] escreveu:
> Sempre ouvi dizer que palavras reservadas do postgre, devem ser escritas
> em caixa alta e objetos em caixa baixa. Sempre segui esta regra com meus
> sql's, gostaria de saber se isso realmente é verdade e se sim, se ajuda
> no desempenho da aplicação.
> 
A caixa alta é só para "destacar" as palavras reservadas.

Não vejo que isso tenha haver com performance mas sim com estilo e facilidade
de ler uma consulta.


-- 
  Euler Taveira de Oliveira
  http://www.timbira.com/
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] problema com transação

[engelnit]

As rotinas rodam através da minha aplicação. Os erros são de execução de
query, consultas e inserts, podendo ocorrer em qualquer tabela ou registro.
Como eu disse, são eventuais, não repetitivos. Eu capturo
esses sqls, e rodo no pgadim, eles executam sem problema. E se eu rodar
novamente a rotina, com transação, nesse grupo de registros que deram erro,
rodará normal, sem erro. Parece que esses erros só 
ocorrem mesmo quando o volume de registro é grande.


Tiago J. Adami wrote:
> 
> Qual(is) o(s) erro(s) exatamente? As rotinas rodam em funções Pl/PgSql ou
> através da sua aplicação?
> 
> -- 
> Tiago J. Adami
> http://www.adamiworks.com
> 
> 
> 2009/10/21 engelnit 
> 
>>
>> Bom dia a todos.
>>
>> Estou com um problema ao trabalhar com transações, que realmente está me
>> intrigando:
>>
>> Fazíamos todos os processamentos de informação do nosso sistema com o
>> autocommit do postrgresql,
>> sem transação. Tudo funcionava bem. Depois de alguns meses, sentimos a
>> necessidade de alterar isso,
>> passando a fazer os processamentos com transação, para poder dar rollback
>> no
>> caso de algum problema de energia, conexão, etc. Aí começaram os
>> problemas.
>>
>> Se a quantidade de registros é pequena, tudo ocorre bem. Porém, se é um
>> pouco maior, tipo 30 mil, começam a acontecer erros na transação. Nesse
>> exemplo dos 30 mil, fazendo direto (autocommit), ele funciona sem
>> problema.
>> Fazendo dentro de uma transação, ele dará erro em mais ou menos uns 25
>> registros. Processando novamente esses 25, tudo funciona bem.
>>
>> Os erros que acontecem nesses 25 ao processar os 30 mil são os mais
>> diversos
>> possíveis: um simples select buscando uma descrição, ou qualquer coisa.
>> São
>> sqls pequenos, rápidos, que rodam sem problema.
>> A questão é essa: pq rodando no autocommit ele funciona, e na transação
>> dá
>> esses erros eventuais?
>>
>> Só pra esclarecer, a transação é aberta, o processamento do registro é
>> feito, e logo é fechada. Isso é repetido para os 30 mil.
>>
>> Agradeço qualquer ajuda, obrigado
>>
>> Arthur
>> --
>> View this message in context:
>> http://www.nabble.com/problema-com-transa%C3%A7%C3%A3o-tp25992523p25992523.html
>> Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com.
>>
>> ___
>> 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
> 
> 

-- 
View this message in context: 
http://www.nabble.com/problema-com-transa%C3%A7%C3%A3o-tp25992523p25993555.html
Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com.

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

[pgbr-geral] Res: Funcao postgres

[Nelson Gonzaga]

inet_client_addr




De: paulo matadr 
Para: pgbr_LISTA 
Enviadas: Qua, Outubro 21, 2009 12:09:54 PM
Assunto: [pgbr-geral] Funcao postgres


Ola pessoal,


um duvida simples, existe uma funcao no postgres que retorne o ip do usuario, 
do tipo:
select get_ip ou algo parecido?

agradeço


Veja quais são os assuntos do momento no Yahoo! + Buscados: Top 10 - 
Celebridades - Música - Esportes


  

Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Funcao postgres

[Fabrízio de Royes Mello]

2009/10/21 paulo matadr 

> Ola pessoal,
>
>
> um duvida simples, existe uma funcao no postgres que retorne o ip do
> usuario, do tipo:
> select get_ip ou algo parecido?
>
>
Sim,

Veja a função "pg_get_backend_client_addr" em [1].


[1] http://www.postgresql.org/docs/8.4/interactive/monitoring-stats.html

-- 
Fabrízio de Royes Mello
>> Blog sobre TI: http://fabriziomello.blogspot.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] caixa alta

[Rodrigo Ibraim [PGOpen]]

Bom dia

Sempre ouvi dizer que palavras reservadas do postgre, devem ser escritas em
caixa alta e objetos em caixa baixa. Sempre segui esta regra com meus sql's,
gostaria de saber se isso realmente é verdade e se sim, se ajuda no
desempenho da aplicação.

Grato

-- 
Rodrigo Ibraim
Consultor em Sistemas
11 2864-0082
11 9292-1548
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Funcao postgres

[paulo matadr]

Ola pessoal,


um duvida simples, existe uma funcao no postgres que retorne o ip do usuario, 
do tipo:
select get_ip ou algo parecido?

agradeço



  

Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] [OT] Caravanas PGCON e transporte para o evento

[Leandro DUTRA]

2009/10/19 Leonardo Cezar :
>
> Um pouco em cima da hora, mas existe alguém interessado em organizar
> caravanas de seus respectivos estados/cidades?
>
> Bom, para aqueles que vem de carro de outras cidades uma sugestão
> seria dar carona pro vizinho e este é o momento de acertar isto.

Eu preciso de carona de São Paulo!  Mas preciso chegar cedo… talvez eu
leve patroa e filho, então, se ninguém tiver lugar, mas puder levar
nosso equipamento… mais ou menos que temos o encargo de fotografar o
evento, se tivermos de ir de ônibus seria legal alguém poder levar o
peso, mesmo que não tenha lugar para a gente.


> Para aqueles que estão em hotéis mais afastados do Centro de
> convenções da Unicamp e gostariam de "rachar" uma carona para se
> locomover até o evento, entrem em contato com chriscezar [_arroba_]
> gmail ponto com para agendar transporte.

Idem, vou escrever… ¿é a tua digníssima?



-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3040 7344  gTalk: xmpp:leand...@jabber.org
+55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT-3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
Sent from Sao Paulo, SP, Brazil
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] problema com transação

[Tiago Adami]

Qual(is) o(s) erro(s) exatamente? As rotinas rodam em funções Pl/PgSql ou
através da sua aplicação?

-- 
Tiago J. Adami
http://www.adamiworks.com


2009/10/21 engelnit 

>
> Bom dia a todos.
>
> Estou com um problema ao trabalhar com transações, que realmente está me
> intrigando:
>
> Fazíamos todos os processamentos de informação do nosso sistema com o
> autocommit do postrgresql,
> sem transação. Tudo funcionava bem. Depois de alguns meses, sentimos a
> necessidade de alterar isso,
> passando a fazer os processamentos com transação, para poder dar rollback
> no
> caso de algum problema de energia, conexão, etc. Aí começaram os problemas.
>
> Se a quantidade de registros é pequena, tudo ocorre bem. Porém, se é um
> pouco maior, tipo 30 mil, começam a acontecer erros na transação. Nesse
> exemplo dos 30 mil, fazendo direto (autocommit), ele funciona sem problema.
> Fazendo dentro de uma transação, ele dará erro em mais ou menos uns 25
> registros. Processando novamente esses 25, tudo funciona bem.
>
> Os erros que acontecem nesses 25 ao processar os 30 mil são os mais
> diversos
> possíveis: um simples select buscando uma descrição, ou qualquer coisa. São
> sqls pequenos, rápidos, que rodam sem problema.
> A questão é essa: pq rodando no autocommit ele funciona, e na transação dá
> esses erros eventuais?
>
> Só pra esclarecer, a transação é aberta, o processamento do registro é
> feito, e logo é fechada. Isso é repetido para os 30 mil.
>
> Agradeço qualquer ajuda, obrigado
>
> Arthur
> --
> View this message in context:
> http://www.nabble.com/problema-com-transa%C3%A7%C3%A3o-tp25992523p25992523.html
> Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com.
>
> ___
> 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] problema com transação

[engelnit]

Bom dia a todos.

Estou com um problema ao trabalhar com transações, que realmente está me
intrigando:

Fazíamos todos os processamentos de informação do nosso sistema com o
autocommit do postrgresql,
sem transação. Tudo funcionava bem. Depois de alguns meses, sentimos a
necessidade de alterar isso,
passando a fazer os processamentos com transação, para poder dar rollback no
caso de algum problema de energia, conexão, etc. Aí começaram os problemas.

Se a quantidade de registros é pequena, tudo ocorre bem. Porém, se é um
pouco maior, tipo 30 mil, começam a acontecer erros na transação. Nesse
exemplo dos 30 mil, fazendo direto (autocommit), ele funciona sem problema.
Fazendo dentro de uma transação, ele dará erro em mais ou menos uns 25
registros. Processando novamente esses 25, tudo funciona bem. 

Os erros que acontecem nesses 25 ao processar os 30 mil são os mais diversos
possíveis: um simples select buscando uma descrição, ou qualquer coisa. São
sqls pequenos, rápidos, que rodam sem problema.
A questão é essa: pq rodando no autocommit ele funciona, e na transação dá
esses erros eventuais? 

Só pra esclarecer, a transação é aberta, o processamento do registro é
feito, e logo é fechada. Isso é repetido para os 30 mil.

Agradeço qualquer ajuda, obrigado

Arthur
-- 
View this message in context: 
http://www.nabble.com/problema-com-transa%C3%A7%C3%A3o-tp25992523p25992523.html
Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com.

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

Re: [pgbr-geral] Ajuda sobre Frequência REINDEX SYST EM / DATABASE

[Fabrízio de Royes Mello]

2009/10/21 André Volpato 

>
> Apenas vacuum periódico.
> Mas se o sistema fosse OLTP, eu iria de autovacuum (da 8.3 em diante...)
>
>
Em um cenário (Linux + PgBouncer + PostgreSQL) estou usando o autovacuum
ativo e a versão do elefantinho é a 8.2... e é um ERP escrito em PHP bem
grande... e estou mto satisfeito com o 8.2, apesar de indicarem usar o 8.3
em diante...

Obrigado!

-- 
Fabrízio de Royes Mello
>> Blog sobre TI: http://fabriziomello.blogspot.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Ajuda sobre Frequência REINDEX SYST EM / DATABASE

[André Volpato]

Fabrízio de Royes Mello escreveu:

  
  2009/10/21 André Volpato 
  
Só metendo o bedelho aqui rapidinho:
Temos uma rotina semanal de REINDEX, e ela funciona muito bem. Não posso
"clusterizar" aqui, já que a aplicação tem um uso de índices bem
variado, mas a questão do "bloat" diminuiu bastante depois do reindex.

Vacuum full jamais...

  
  
  
Perfeito... e vc utiliza o auto_vacuum ativo ou agenda um vacuum
periódico?
  


Apenas vacuum periódico. 
Mas se o sistema fosse OLTP, eu iria de autovacuum (da 8.3 em diante...)

[]´s, André Volpato


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

Re: [pgbr-geral] Ajuda sobre Frequência REINDEX SYST EM / DATABASE

[Fabrízio de Royes Mello]

2009/10/21 André Volpato 

>
> Só metendo o bedelho aqui rapidinho:
> Temos uma rotina semanal de REINDEX, e ela funciona muito bem. Não posso
> "clusterizar" aqui, já que a aplicação tem um uso de índices bem
> variado, mas a questão do "bloat" diminuiu bastante depois do reindex.
>
> Vacuum full jamais...
>
>
Perfeito... e vc utiliza o auto_vacuum ativo ou agenda um vacuum periódico?

-- 
Fabrízio de Royes Mello
>> Blog sobre TI: http://fabriziomello.blogspot.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] [OFF] Oportunidade CTIS

[Pablo Sánchez]

Repassando...

=

Necessitamos de profissionais  para prestação de serviços no contrato da
Caixa Econômica:



Analista de Integração/ETL
-Conhecimento da plataforma INFORMATICA PowerCenter 8.6;
-Experiência em projetos de integração, migração, sincronização e
datawarehousing;
-Conhecimentos de técnicas de modelagem multidimensional, relacional;
-Conhecimentos de modelagem, arquitetura e técnicas OLAP;

Analista de Metadados
-Conhecimento da plataforma INFORMATICA Metadata Manager;
-Experiência em definição de metadados customizados, importação de metadados
no Metadata Manager;
-Conhecimentos de metamodelos, tipos de repositório de metadados, análises
Where Used e Data Lineage;
-Conhecimento da Ferramenta de Modelagem PowerDesigner;
-Conhecimento de padrões de interoperabilidade de metadados, em especial
e-Ping, PMG e padrão OMG/CWM;



Necessário Gradução ou Especialização  na área de TI o



Interessados pedimos gentileza encaminhar CV para lia.kuwayama@
ctis.com. 
br



Lia Kuwayama

Gerente de Projeto

CTIS

-- 
=
Pablo Santiago Sánchez
Análise e Desenvolvimento de Sistemas Web
Zend Certified Engineer #ZEND006757
phack...@gmail.com
(61) 9975-0883
http://www.sanchez.eti.br
http://www.corephp.com.br
"Quidquid latine dictum sit, altum viditur"
=
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Ajuda sobre Frequência REINDEX SYST EM / DATABASE

[André Volpato]

Fabrízio de Royes Mello escreveu:
>
>
> A minha questão principal é sobre as atividades de manutenção (algumas 
> dúvidas foram descartadas e outras tenho que colocar em prática e 
> verificar o resultado prático) e a degradação de performance ao longo 
> do tempo que acaba somente se resolvendo com um Drop/Restore da 
> base... claro que agora vc indicou a questão do "inchaço" dos índices 
> e recomendou usar CLUSTER + REINDEX no lugar do VACUUM FULL.
>

Só metendo o bedelho aqui rapidinho:
Temos uma rotina semanal de REINDEX, e ela funciona muito bem. Não posso 
"clusterizar" aqui, já que a aplicação tem um uso de índices bem 
variado, mas a questão do "bloat" diminuiu bastante depois do reindex.

Vacuum full jamais...

[]´s, ACV

___
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] Software Livre para M unicípios utiliza PostgreSQL

[Fabrízio de Royes Mello]

2009/10/21 MARCIO CASTRO 

> Colega; essa ferramenta é gratuita? Não tem de pagar qualquer licença ou
> taxa de manutenção?
>
>
Exatamente... como mencionei será lançada no evento do SPB na próxima semana
em Brasília sob a licença GPL [1]

[1] http://pt.wikipedia.org/wiki/GNU_General_Public_License

-- 
Fabrízio de Royes Mello
>> Blog sobre TI: http://fabriziomello.blogspot.com
___
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] Software Livr e para Municípios utiliza PostgreSQL

[MARCIO CASTRO]

Colega; essa ferramenta é gratuita? Não tem de pagar qualquer licença ou taxa 
de manutenção?






De: Fabrízio de Royes Mello 
Para: Comunidade PostgreSQL Brasileira ; 
Organização do PostgreSQL Brasil 
Enviadas: Qua, Outubro 21, 2009 12:41:41 AM
Assunto: [pgbr-geral] [Off-Topic] Software Livre para Municípios utiliza 
PostgreSQL

Caros Colegas,

Nosso GRP (Government Resource Planning) será disponibilizado, sob licença 
GPL2, no Portal do Software Público Brasileiro [1] conforme noticia no site do 
Ministério do Planejamento [2].

Nossa aplicação antes chamada DBPortal [3], agora denominada e-Cidade, está em 
produção em 15 municipios Brasileiros. É uma ferramenta 100% Web, escrita em 
PHP 5 e PostgreSQL (muita rotinas implementada em pl/pgsql).

Um trecho da noticia [2]: 

"Os
municípios brasileiros terão à disposição um software público capaz de
gerenciar em um único sistema as principais áreas da prefeitura.
Trata-se do e-cidade, desenvolvido para integrar áreas diversas do
município como educação, controle de medicamentos, orçamento, finanças
públicas, recursos humanos e tributária. A solução também permite gerir
serviços que prestam atendimento ao cidadão ao gerar guias para
pagamento bancário sem a necessidade de deslocamento. 
Todas
as prefeituras poderão acessar a ferramenta e-cidade, que será lançada
e disponibilizada gratuitamente no Encontro Nacional de Tecnologia da
Informação para os Municípios Brasileiros. O evento será promovido pelo
Ministério do Planejamento, nos dias 27 e 28 de outubro, no Centro de
Convenções Brasil 21, em Brasília."
[1] http://www.softwarepublico.gov.br/
[2] http://www.planejamento.gov.br/noticia.asp?p=not&cod=4463&cat=94&sec=7
[3] http://www.dbseller.com.br

-- 
Fabrízio de Royes Mello
>> Blog sobre TI: http://fabriziomello.blogspot.com



  

Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Ajuda sobre Frequência REINDEX SYST EM / DATABASE

[Fabrízio de Royes Mello]

2009/10/21 Euler Taveira de Oliveira 

> Talvez investigar isso utilizando um strace ou similar no processo de
> limpeza.
> Pode ser que algum software "malicioso" (aka anti-*) esteja provocando esse
> "congelamento"?
>
>
Isso não é improvável... mas reiniciando o servidor tudo volta ao
"normal"... isso que nos deixa confusos... no anti-virus ignoramos a pasta
do cluster e, por último, por "desespero" ignoramos até a pasta dos binários
tb... porém sem sucesso...

Vou dar uma olhada no strace e verificar que resultados posso obter dele...


> a única coisa que resolveu o problema, num primeiro momento,
> > foi reiniciar o servidor antes da manutenção
> >
> Desculpe mas porque não utiliza um sistema operacional de verdade. ;)
>
>
Eu sei da questão de arquitetura do PostgreSQL em relação ao Windows que foi
criado todo um port emulando várias coisas que o windows não faz e assim por
diante... mas convenhamos, o PostgreSQL funciona e muito bem nessa
plataforma (estamos usando desde que foi lançada a versão nativa)... é claro
que no Linux tem um desempenho superior, mas outras questões técnicas (e tb
não técnicas) nesse cenário nos fazem não mudar a plataforma de S.O. neste
momento.

Não gostaria, neste momento, de levar o rumo dessa thread para discussões
sobre qual S.O. melhor se encaixa para o PostgreSQL... deixemos essa questão
para outra thread, senão vc sabe bem o que acontece... acaba virando
discussão sobre "o sexo dos anjos"...

A minha questão principal é sobre as atividades de manutenção (algumas
dúvidas foram descartadas e outras tenho que colocar em prática e verificar
o resultado prático) e a degradação de performance ao longo do tempo que
acaba somente se resolvendo com um Drop/Restore da base... claro que agora
vc indicou a questão do "inchaço" dos índices e recomendou usar CLUSTER +
REINDEX no lugar do VACUUM FULL.

Cordialmente,
-- 
Fabrízio de Royes Mello
>> Blog sobre TI: http://fabriziomello.blogspot.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] [pgbr-dev] [Off-Topic] Software Li vre para Municípios utiliza PostgreSQL

[Fábio Telles Rodriguez]

Se vocês estiverem no PGCon Brasil, recomendo que se inscrevam nos
Lightinig Talks para contar a novidade...

[]s
Fábio Telles

blog: http://www.midstorm.org/~telles/
e-mail / jabber: fabio.tel...@gmail.com



2009/10/21 Fabrízio de Royes Mello :
> Caros Colegas,
>
> Nosso GRP (Government Resource Planning) será disponibilizado, sob licença
> GPL2, no Portal do Software Público Brasileiro [1] conforme noticia no site
> do Ministério do Planejamento [2].
>
> Nossa aplicação antes chamada DBPortal [3], agora denominada e-Cidade, está
> em produção em 15 municipios Brasileiros. É uma ferramenta 100% Web, escrita
> em PHP 5 e PostgreSQL (muita rotinas implementada em pl/pgsql).
>
> Um trecho da noticia [2]:
>
> "Os municípios brasileiros terão à disposição um software público capaz de
> gerenciar em um único sistema as principais áreas da prefeitura. Trata-se do
> e-cidade, desenvolvido para integrar áreas diversas do município como
> educação, controle de medicamentos, orçamento, finanças públicas, recursos
> humanos e tributária. A solução também permite gerir serviços que prestam
> atendimento ao cidadão ao gerar guias para pagamento bancário sem a
> necessidade de deslocamento.
>
> Todas as prefeituras poderão acessar a ferramenta e-cidade, que será lançada
> e disponibilizada gratuitamente no Encontro Nacional de Tecnologia da
> Informação para os Municípios Brasileiros. O evento será promovido pelo
> Ministério do Planejamento, nos dias 27 e 28 de outubro, no Centro de
> Convenções Brasil 21, em Brasília."
>
> [1] http://www.softwarepublico.gov.br/
> [2] http://www.planejamento.gov.br/noticia.asp?p=not&cod=4463&cat=94&sec=7
> [3] http://www.dbseller.com.br
>
> --
> Fabrízio de Royes Mello
>>> Blog sobre TI: http://fabriziomello.blogspot.com
>
> ___
> pgbr-dev mailing list
> pgbr-...@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-dev
>
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral