Re: [pgbr-geral] Error postgresql

[Fabricio Silva]

Flavio, boa noite.

Estou utilizando a versão Ubuntu 12.04.4 LTS com todos os pacotes
atualizados (atualmente estou somente atualizando os pacotes de segurança
disponibilizados pela canonical


Em 22 de agosto de 2014 06:03, Flavio Henrique Araque Gurgel <
fha...@gmail.com> escreveu:

> Boa noite,
>> Hoje apareceu a seguinte mensagem nos logs do postgresql
>>
>> 2014-08-21 18:37:05 BRT [10504]: [2-1] user=xxx,db=
>> STATEMENT:  SELECT table_name as name FROM INFORMATION_SCHEMA.tables
>> WHERE table_schema = 'public';
>>
>> 2014-08-21 18:37:05 BRT [10504]: [3-1] user=,db= LOG:  SSL
>> error: bad write retry
>>
>> 2014-08-21 18:37:05 BRT [10504]: [4-1] user=,db= LOG:  could not
>> receive data from client: Connection reset by peer
>>
>> 2014-08-21 18:37:05 BRT [10504]: [5-1] user=,db=
>> LOG:  unexpected EOF on client connection
>>
>>
>> Por se tratar de um ambiente de homologação reiniciei o servico do
>> postgresql e a mensagem náo apareceu mais, porém gostaria de saber do
>> que se trata...
>>
>
> É um bug da libssl, não relacionado ao PostgreSQL. O tráfego de dados
> entre cliente e servidor se interrompe e o PostgreSQL fecha a conexão.
> Seu sistema operacional está atualizado?
>
> []s
> Flavio Gurgel
> ___
> 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] Ajuda com select

[Danilo Silva]

Em 22 de agosto de 2014 21:50, Danilo Silva 
escreveu:

>
> Em 22 de agosto de 2014 21:43, Danilo Silva 
> escreveu:
>
> Pessoal,
>>
>> Possuo uma tabela de histórico de leitura, onde cada registro possui o id
>> da tabela pai:
>>
>> tabela_documento = tabela pai (contém os dados principais do objeto)
>> tabela_historico = historico de leituras (contém data, hora, origem e
>> destino de cada objeto).
>>
>> Resumindo, para cada registro na tabela pai, eu posso ter vários
>> registros na tabela de histórico.
>>
>> O meu problema está que por uma falha na programação, o sistema não
>> obedeceu essa regra, ficou no relacionamento 1 para 1.
>>
>> Preciso agora corrigir isso, pegar todos os registros da tabela de
>> histórico e atualizá-los com um único id da tabela pai correspondente.
>>
>> Pensei em utilizar a querie abaixo, onde eu monto o comando de update na
>> tabela de histórico e delete na tabela pai
>>
>> SELECT
>> , 'UPDATE historico SET idpai =
>> '||split_part(string_agg(idpai::text,','),',',1)||' WHERE (idhistorico IN
>> ('||string_agg(idhistorico::text,',')||'));'
>> , 'DELETE FROM tabela_pai WHERE (idpai IN
>> ('||string_agg(idpai::text,',')||')) AND (idpai <>
>> '||split_part(string_agg(idpai::text,','),',',1)||');'
>> FROM historico GROUP BY codempresa,codcliente,codproduto,codbarras HAVING
>> COUNT(*) > 1
>>
>> mas encontrei 2 problemas, o primeiro é a demora no select, cancelei o
>> select após 25 minutos (a tabela possui em torno de 980 mil registros), o
>> segundo é o limite de caracteres de retorno da função string_agg (retorna
>> parte dos códigos, pois no final fica "(...)".
>>
>> Vamos lá, existe uma forma melhor de executar o eu preciso?
>>
>> A função string_agg realmente possui essa limitação?
>>
>>
>> ​Pessoal esqueci de mencionar que executei a select no pgadmin, estive
> vendo pelo psql e parece que a limitação de caracteres da função string_agg
> não acontece, talvez seja alguma coisa do pgadmin.
>
>
> ​Pessoal,

Consegui executar o select através do comando COPY TO (levou 20s e retornou
16 mil registros), parece que a limitação foi mesmo com o pgadmin, pois a
função string_agg retornou todos os códigos.

[]s
Danilo ​
___
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 com select

[Danilo Silva]

Em 22 de agosto de 2014 21:43, Danilo Silva 
escreveu:

> Pessoal,
>
> Possuo uma tabela de histórico de leitura, onde cada registro possui o id
> da tabela pai:
>
> tabela_documento = tabela pai (contém os dados principais do objeto)
> tabela_historico = historico de leituras (contém data, hora, origem e
> destino de cada objeto).
>
> Resumindo, para cada registro na tabela pai, eu posso ter vários registros
> na tabela de histórico.
>
> O meu problema está que por uma falha na programação, o sistema não
> obedeceu essa regra, ficou no relacionamento 1 para 1.
>
> Preciso agora corrigir isso, pegar todos os registros da tabela de
> histórico e atualizá-los com um único id da tabela pai correspondente.
>
> Pensei em utilizar a querie abaixo, onde eu monto o comando de update na
> tabela de histórico e delete na tabela pai
>
> SELECT
> , 'UPDATE historico SET idpai =
> '||split_part(string_agg(idpai::text,','),',',1)||' WHERE (idhistorico IN
> ('||string_agg(idhistorico::text,',')||'));'
> , 'DELETE FROM tabela_pai WHERE (idpai IN
> ('||string_agg(idpai::text,',')||')) AND (idpai <>
> '||split_part(string_agg(idpai::text,','),',',1)||');'
> FROM historico GROUP BY codempresa,codcliente,codproduto,codbarras HAVING
> COUNT(*) > 1
>
> mas encontrei 2 problemas, o primeiro é a demora no select, cancelei o
> select após 25 minutos (a tabela possui em torno de 980 mil registros), o
> segundo é o limite de caracteres de retorno da função string_agg (retorna
> parte dos códigos, pois no final fica "(...)".
>
> Vamos lá, existe uma forma melhor de executar o eu preciso?
>
> A função string_agg realmente possui essa limitação?
>
>
> ​Pessoal esqueci de mencionar que executei a select no pgadmin, estive
vendo pelo psql e parece que a limitação de caracteres da função string_agg
não acontece, talvez seja alguma coisa do pgadmin.

[]s
Danilo​
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Ajuda com select

[Danilo Silva]

Pessoal,

Possuo uma tabela de histórico de leitura, onde cada registro possui o id
da tabela pai:

tabela_documento = tabela pai (contém os dados principais do objeto)
tabela_historico = historico de leituras (contém data, hora, origem e
destino de cada objeto).

Resumindo, para cada registro na tabela pai, eu posso ter vários registros
na tabela de histórico.

O meu problema está que por uma falha na programação, o sistema não
obedeceu essa regra, ficou no relacionamento 1 para 1.

Preciso agora corrigir isso, pegar todos os registros da tabela de
histórico e atualizá-los com um único id da tabela pai correspondente.

Pensei em utilizar a querie abaixo, onde eu monto o comando de update na
tabela de histórico e delete na tabela pai

SELECT
, 'UPDATE historico SET idpai =
'||split_part(string_agg(idpai::text,','),',',1)||' WHERE (idhistorico IN
('||string_agg(idhistorico::text,',')||'));'
, 'DELETE FROM tabela_pai WHERE (idpai IN
('||string_agg(idpai::text,',')||')) AND (idpai <>
'||split_part(string_agg(idpai::text,','),',',1)||');'
FROM historico GROUP BY codempresa,codcliente,codproduto,codbarras HAVING
COUNT(*) > 1

mas encontrei 2 problemas, o primeiro é a demora no select, cancelei o
select após 25 minutos (a tabela possui em torno de 980 mil registros), o
segundo é o limite de caracteres de retorno da função string_agg (retorna
parte dos códigos, pois no final fica "(...)".

Vamos lá, existe uma forma melhor de executar o eu preciso?

A função string_agg realmente possui essa limitação?

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

Re: [pgbr-geral] usuario postgres marcado como account expires

[Fabrízio de Royes Mello]

On 22-08-2014 17:41, Matheus de Oliveira wrote:

2014-08-22 17:09 GMT-03:00 Fabrízio de Royes Mello 
:


Boa tarde pessoal,

veja se alguém poderia me ajudar,
um técnico nosso foi alterar a senha do postgres e marcou a opção account
expires com data de hoje.
como posso fazer para desmarcar essa opção no caso de não ter outro super
administrador.



Desabilita a autenticação no pg_hba.conf colocando "trust" lá.




Isso funciona para contas expiradas?

Sei não se não tiver outro superuser para fazer essa operação talvez seja
necessário entrar em singlemode. Mas sinceramente nunca me deparei com uma
situação dessas. 8-P



Funciona sim... como dizia o seu Creysson "eu agarantium"... ;-)


--
   Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] usuario postgres marcado como account expires

[Matheus de Oliveira]

2014-08-22 17:31 GMT-03:00 Douglas Fabiano Specht 
:

> Valeu pela resposta pessoal, como sempre muito prestativos..
> ja tinha entrado via psql e rodado o comando:
>
> ALTER USER postgres VALID UNTIL 'infinity'
>


Ah... Eu não vi essa mensagem... Se deu tempo de passar pra "infinity",
blz... :-D


-- 
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
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] usuario postgres marcado como account expires

[Matheus de Oliveira]

2014-08-22 17:09 GMT-03:00 Fabrízio de Royes Mello 
:

> Boa tarde pessoal,
>> veja se alguém poderia me ajudar,
>> um técnico nosso foi alterar a senha do postgres e marcou a opção account
>> expires com data de hoje.
>> como posso fazer para desmarcar essa opção no caso de não ter outro super
>> administrador.
>>
>>
> Desabilita a autenticação no pg_hba.conf colocando "trust" lá.



Isso funciona para contas expiradas?

Sei não se não tiver outro superuser para fazer essa operação talvez seja
necessário entrar em singlemode. Mas sinceramente nunca me deparei com uma
situação dessas. 8-P

Atenciosamente,
-- 
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
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] usuario postgres marcado como account expires

[Douglas Fabiano Specht]

2014-08-22 17:11 GMT-03:00 Euler Taveira :

> On 22-08-2014 17:03, Douglas Fabiano Specht wrote:
> > um técnico nosso foi alterar a senha do postgres e marcou a opção account
> > expires com data de hoje.
> > como posso fazer para desmarcar essa opção no caso de não ter outro super
> > administrador.
> >
> No pg_hba.conf coloque uma regra 'trust' para role postgres.
>
>
> --
>Euler Taveira   Timbira - http://www.timbira.com.br/
>PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>

Valeu pela resposta pessoal, como sempre muito prestativos..
ja tinha entrado via psql e rodado o comando:

ALTER USER postgres VALID UNTIL 'infinity'

-- 

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

Re: [pgbr-geral] PostgreSQL e CentOS 7

[Leonardo Ferreira Guimarães]

>
> Pessoal,
>
> Alguem esta usando o CentOS 7 com o postgreSQL, notou alguma diferença
> para a versão 6.X ?
>

Olá Gustavo.

Atualmente estou tratando uma base em ambiente produção com COS7 e não
sentimos nenhuma alteração.
Acredito que só teremos benefícios pelo fato da atualização para o Kernel 3.
Faça as suas implementações e nos dê um feedback também.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] usuario postgres marcado como account expires

[Euler Taveira]

On 22-08-2014 17:03, Douglas Fabiano Specht wrote:
> um técnico nosso foi alterar a senha do postgres e marcou a opção account
> expires com data de hoje.
> como posso fazer para desmarcar essa opção no caso de não ter outro super
> administrador.
> 
No pg_hba.conf coloque uma regra 'trust' para role postgres.


-- 
   Euler Taveira   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] usuario postgres marcado como account expires

[Fabrízio de Royes Mello]

On 22-08-2014 17:03, Douglas Fabiano Specht wrote:

Boa tarde pessoal,
veja se alguém poderia me ajudar,
um técnico nosso foi alterar a senha do postgres e marcou a opção account
expires com data de hoje.
como posso fazer para desmarcar essa opção no caso de não ter outro super
administrador.



Desabilita a autenticação no pg_hba.conf colocando "trust" lá.

:-)

--
   Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] usuario postgres marcado como account expires

[Douglas Fabiano Specht]

Boa tarde pessoal,
veja se alguém poderia me ajudar,
um técnico nosso foi alterar a senha do postgres e marcou a opção account
expires com data de hoje.
como posso fazer para desmarcar essa opção no caso de não ter outro super
administrador.

postgres 9.2
centOS 6.4



-- 

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

Re: [pgbr-geral] Atualizar estatísticas

[Flavio Henrique Araque Gurgel]

Levando em consideração que o autovacuum sempre estará ligado, não é
necessário rodar o analyse, certo? Ou eu posso ter que rodar caso queira
que a atualização seja imediata, pois o autovacuum não é rodado de
tempos em tempos, mas sim de acordo com a necessidade da tabela, certo?


Normalmente não há necessidade de rodar um ANALYZE manualmente. Existem 
casos como logo após a criação de índices, um vacuum full ou alteração 
de estrutura, mas mesmo nesses casos nas versões mais recentes existem 
otimizações que reduzem essa carga de trabalho manual.


Todavia, a regra é simples, tempo não é indicador de necessidade de 
fazer alguma manutenção num banco de dados, tudo depende das mudanças 
feitas nos dados.


[]s
Flavio Gurgel
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Desempenho para selects

[Flavio Henrique Araque Gurgel]

Em 22 de agosto de 2014 12:39, Flavio Henrique Araque Gurgel
mailto:fha...@gmail.com>> escreveu:

Pessoal,

É possível configurar o postgres de forma a obter um melhor
desempenho,
considerando que os selects representam 80% das requisições?


Sim.

​Quais parâmetros de configuração devem ser considerados? É possível
chegar a algum valor, ou existe alguma conta que deve ser feita/analisada?​


Talvez você deva pesquisar e ler um pouco, existe muito material na 
Internet sobre isso. Em seguida, você vêm com perguntas mais específicas.


No geral, as configurações padrão são bastante conservadoras e sempre há 
melhorias a fazer. Tem muita análise, o que seu sistema faz, como são as 
consultas, se você terá de privilegiar disco, memória, CPU e etc.



Os "where" e "order by" dos selects são baseados nos índicies
existentes
em cada tabela.


Isso é uma boa ideia em tempo de projeto mas pode variar depois que
o banco está em produção.


​Mas que tipo de variação pode ocorrer?


Quem decide se um índice será usado é o planejador. Tudo depende do 
tamanho da tabela, distribuição estatística dos dados, quantidade de 
linhas a verificar e a realmente mostrar. As variáveis são muitas e 
variam em tempo de desenvolvimento e produção real.


[]s
Flavio Gurgel
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Atualizar estatísticas

[Flavio Henrique Araque Gurgel]

Em 22 de agosto de 2014 12:39, Flavio Henrique Araque Gurgel
mailto:fha...@gmail.com>> escreveu:

Pessoal,

Qual comando deve ser executado (se é que é necessário) para
atualizar
as estatísticas?


ANALYZE;

O ANALYSE pode ser rodado frequentemente? Quando rodado, ocorre algum
tipo de lock exclusivo?


Deixe o autovacuum ligado que ele passará o analyze automaticamente para 
você de acordo com a necessidade de cada tabela.


Não há lock exclusivo.

[]s
Flavio Gurgel
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Desempenho para selects

[Danilo Silva]

Em 22 de agosto de 2014 12:39, Flavio Henrique Araque Gurgel <
fha...@gmail.com> escreveu:

> Pessoal,
>>
>> É possível configurar o postgres de forma a obter um melhor desempenho,
>> considerando que os selects representam 80% das requisições?
>>
>
> Sim.

​Quais parâmetros de configuração devem ser considerados? É possível chegar
a algum valor, ou existe alguma conta que deve ser feita/analisada?​


>
>
>
>> Os "where" e "order by" dos selects são baseados nos índicies existentes
>> em cada tabela.
>>
>
> Isso é uma boa ideia em tempo de projeto mas pode variar depois que o
> banco está em produção.
>
>
> ​Mas que tipo de variação pode ocorrer?

[]s
Danilo​
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Atualizar estatísticas

[Danilo Silva]

Em 22 de agosto de 2014 12:47, Flavio Henrique Araque Gurgel <
fha...@gmail.com> escreveu:

> Em 22 de agosto de 2014 12:39, Flavio Henrique Araque Gurgel
>> mailto:fha...@gmail.com>> escreveu:
>>
>>
>> Pessoal,
>>
>> Qual comando deve ser executado (se é que é necessário) para
>> atualizar
>> as estatísticas?
>>
>>
>> ANALYZE;
>>
>> O ANALYSE pode ser rodado frequentemente? Quando rodado, ocorre algum
>> tipo de lock exclusivo?
>>
>
> Deixe o autovacuum ligado que ele passará o analyze automaticamente para
> você de acordo com a necessidade de cada tabela.
>
> Não há lock exclusivo.
>
>
> Levando em consideração que o autovacuum sempre estará ligado, não é
necessário rodar o analyse, certo? Ou eu posso ter que rodar caso queira
que a atualização seja imediata, pois o autovacuum não é rodado de tempos
em tempos, mas sim de acordo com a necessidade da tabela, certo?

[]s
Danilo​
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Atualizar estatísticas

[Danilo Silva]

Em 22 de agosto de 2014 12:39, Flavio Henrique Araque Gurgel <
fha...@gmail.com> escreveu:

> Pessoal,
>>
>> Qual comando deve ser executado (se é que é necessário) para atualizar
>> as estatísticas?
>>
>
> ANALYZE;
>
> O ANALYSE pode ser rodado frequentemente? Quando rodado, ocorre algum tipo
de lock exclusivo?

[]s
Danilo​
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Atualizar estatísticas

[Flavio Henrique Araque Gurgel]

Pessoal,

Qual comando deve ser executado (se é que é necessário) para atualizar
as estatísticas?


ANALYZE;

[]s
Flavio Gurgel
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Desempenho para selects

[Flavio Henrique Araque Gurgel]

Pessoal,

É possível configurar o postgres de forma a obter um melhor desempenho,
considerando que os selects representam 80% das requisições?


Sim.



Os "where" e "order by" dos selects são baseados nos índicies existentes
em cada tabela.


Isso é uma boa ideia em tempo de projeto mas pode variar depois que o 
banco está em produção.


[]s
Flavio Gurgel
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Atualizar estatísticas

[Danilo Silva]

Pessoal,

Qual comando deve ser executado (se é que é necessário) para atualizar as
estatísticas?

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

[pgbr-geral] Desempenho para selects

[Danilo Silva]

Pessoal,

É possível configurar o postgres de forma a obter um melhor desempenho,
considerando que os selects representam 80% das requisições?

Os "where" e "order by" dos selects são baseados nos índicies existentes em
cada tabela.

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

Re: [pgbr-geral] ALTER COLUMN

[Nilton Linhares]

Erlon,

que eu saíba não, já tive que fazer isso uma vez, quando são muitas views é
bem chato hehehe


__

*Nilton Linhares*
Analista de Sistemas

__

*De que serve ao homem conquistar o mundo inteiro se perder a alma?Marcos
8:36 *


Em 22 de agosto de 2014 09:43, fors...@forsell.com.br <
fors...@forsell.com.br> escreveu:

>Bom dia,
>
> Eu trabalho bastante com views gravadas no banco de dados, toda vez que
> preciso aumentar o tamanho de uma coluna, eu preciso excluir as views que
> contem aquela tabela e depois recriar com a mesma estrutura que estavam.
>
> Como não existe nenhuma alteração efetivamente na view, não tem como dar o
> alter column ou alterar a coluna sem que eu tenha que excluir as views e
> recriá-las?
>
> Att,
>
> Erlon
>
> ___
> 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] Fwd: PGDay Campinas 2014 | Inscreva-se agora e ganhe uma camiseta exclusiva!

[Matheus Ricardo Espanhol]

  Caso não consiga visualizar este e-mail, clique aqui

e
veja online



Ainda dá tempo de se inscrever no
*:: PGDAYCAMPINAS 2014 ::*







*

Copyright © 2014 Dextra Sistemas, All rights reserved.*
Você está recebendo este email pois solicitou informações da Dextra ou
participou de eventos patrocinados pela Dextra.

*Our mailing address is:*
Dextra Sistemas
Rod SP 340 Km 118.5
Predio 9A
Campinas, SP 13086-602
Brazil

Add us to your address book



unsubscribe from this list

update subscription preferences

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

Re: [pgbr-geral] ALTER COLUMN

[Flavio Henrique Araque Gurgel]

Bom dia,
Eu trabalho bastante com views gravadas no banco de dados, toda vez que
preciso aumentar o tamanho de uma coluna, eu preciso excluir as views
que contem aquela tabela e depois recriar com a mesma estrutura que estavam.
Como não existe nenhuma alteração efetivamente na view, não tem como dar
o alter column ou alterar a coluna sem que eu tenha que excluir as views
e recriá-las?


Esta pergunta é bastante recorrente e a resposta é não, não há como.
O que algumas pessoas fazem é utilizar restrições (constraints) sobre um 
campo text ao invés de varchar.


Alterar restrições não requer recriar as visões (views).

[]s
Flavio Gurgel
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] ALTER COLUMN

[Matheus de Oliveira]

2014-08-22 9:43 GMT-03:00 fors...@forsell.com.br :

> Eu trabalho bastante com views gravadas no banco de dados, toda vez que
> preciso aumentar o tamanho de uma coluna, eu preciso excluir as views que
> contem aquela tabela e depois recriar com a mesma estrutura que estavam.
>
> Como não existe nenhuma alteração efetivamente na view, não tem como dar o
> alter column ou alterar a coluna sem que eu tenha que excluir as views e
> recriá-las?
>


Vejo duas soluções para o seu caso:

1. Não use colunas (ao menos varchar, para numeric pode não ser tão
simples) com limite de tamanho. Caso esse limite seja realmente uma regra
de negócio, você pode adicionar uma constraint CHECK na tabela delimitando
esse tamanho, daí ao alterar o limite basta alterar a constraint CHECK, que
não terá dependências (por outro lado alterá-la vai sempre requirir uma
verificação completa da tabela). No PostgreSQL o limite de tamanho não
ajuda em nada em termos de otimização ou espaço, é apenas uma verificação
na inserção ou alteração de um registro, ou seja, os tipos `text`,
`varchar` e `varchar(n)` são idênticos, mas o último faz uma validação.

2. Na definição da view, faça uma conversão explícita (cast) dos campos
para um tipo sem limite de tamanho. Assim você não precisa recriar a
tabela, mas ainda assim terá que alterar a view para não ter consulta
envolvendo a tabela ou ao menos o campo (troque os campos por NULL::tipo),
altere a tabela, e restaure a consulta original da view (não é difícil
criar um script que faça isso "automagicamente").

Atenciosamente,
-- 
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
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

[pgbr-geral] ALTER COLUMN

[fors...@forsell.com.br]

Bom dia,

Eu trabalho bastante com views gravadas no banco de dados, toda vez que
preciso aumentar o tamanho de uma coluna, eu preciso excluir as views que
contem aquela tabela e depois recriar com a mesma estrutura que estavam.

Como não existe nenhuma alteração efetivamente na view, não tem como dar o
alter column ou alterar a coluna sem que eu tenha que excluir as views e
recriá-las?

Att,

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

[pgbr-geral] PostgreSQL e CentOS 7

[Gustavo Freitas]

Pessoal,

Alguem esta usando o CentOS 7 com o postgreSQL, notou alguma diferença
para a versão 6.X ?

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

Re: [pgbr-geral] Error postgresql

[Flavio Henrique Araque Gurgel]

Boa noite,
Hoje apareceu a seguinte mensagem nos logs do postgresql

2014-08-21 18:37:05 BRT [10504]: [2-1] user=xxx,db=
STATEMENT:  SELECT table_name as name FROM INFORMATION_SCHEMA.tables
WHERE table_schema = 'public';

2014-08-21 18:37:05 BRT [10504]: [3-1] user=,db= LOG:  SSL
error: bad write retry

2014-08-21 18:37:05 BRT [10504]: [4-1] user=,db= LOG:  could not
receive data from client: Connection reset by peer

2014-08-21 18:37:05 BRT [10504]: [5-1] user=,db=
LOG:  unexpected EOF on client connection


Por se tratar de um ambiente de homologação reiniciei o servico do
postgresql e a mensagem náo apareceu mais, porém gostaria de saber do
que se trata...


É um bug da libssl, não relacionado ao PostgreSQL. O tráfego de dados 
entre cliente e servidor se interrompe e o PostgreSQL fecha a conexão.

Seu sistema operacional está atualizado?

[]s
Flavio Gurgel
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral