Re: [pgbr-geral] Conexão com banco SQL Server
On 06-03-2012 11:43, Charles Emanuel Silva Ramos Patrocínio dos Santos wrote: Estou usando a 8.3 do PostgreSQL e a 2008 R2 do SQL Server. Dê uma olhada em dblink-tds [1], dbi-link[2] e odbclink [3]. Se o PostgreSQL estiver em um servidor Windows, a única opção é o odbclink. (Há *muito* tempo não testo essas ferramentas, portanto, não sei se as mesmas estão funcionando adequadamente). [1] http://pgfoundry.org/projects/dblink-tds/ [2] http://pgfoundry.org/projects/dbi-link/ [3] http://pgfoundry.org/projects/odbclink/ -- Euler Taveira de Oliveira - 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] PG_DUMP - Problema com Blobs
On 05-03-2012 12:08, Gustavo Scudeler wrote: * Sim, tentei com o LIMIT e OFFSET, mas nessa tabela o problema ocorre apenas quando arquivo é maior do que 75 mb +-, ja tentei inserir novamente ou com outros métodos, o problema sempre acontece quando o bytea esta grande,. Eu tentei reproduzir o seu problema com PostgreSQL 8.4.11 (configuração padrão) em um Windows XP x64 SP2 com 512 MB mas não tive sucesso. :( CREATE TABLE foo (id serial, arquivo bytea, PRIMARY KEY(id)); Utilizei arquivos de 10, 30 e 75 MB. Eu testei com um número pequeno de registros. Com quantos você consegue reproduzir este problema? Você não limitou os recursos do usuário postgres do Windows no Windows System Resource Manager? A partir da 9.0, já existe uma versão 64 bits para Windows. Você consegue reproduzir o mesmo problema nessa versão ou mesmo na 9.1? -- Euler Taveira de Oliveira - 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] PG_DUMP - Problema com Blobs
On 04-03-2012 01:15, SteelMason wrote: ERROR: out of memory Failed on request of size 393029321 Você consegue fazer um SELECT chave,campoblob FROM tabela ? Talvez alguns registros estejam corrompidos. Se apresentar erro, tente descobrir quais os registros problemáticos utilizando LIMIT (intervalo à esquerda) e/ou OFFSET (intervalo à direita) em intervalos cada vez menores. -- Euler Taveira de Oliveira - 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] PG_DUMP - Problema com Blobs
On 04-03-2012 14:30, Steel Mason wrote:
Referente ao Select na base, ocorre o mesmo erro ERROR: out of memory Failed
on request of size 393029321
Você tentou o SELECT com LIMIT/OFFSET que eu disse?
Qual o valor dos seguintes parâmetros?
SELECT name,setting FROM pg_settings WHERE name IN ('shared_buffers',
'wal_buffers', 'max_connections', 'autovacuum_max_workers',
'max_locks_per_transaction', 'max_prepared_transactions', 'block_size',
'wal_block_size');
Experimente diminuir o parâmetro shared_buffers para sobrar memória para o
processo servidor que faz a cópia de segurança.
Sera que existe algum parâmetro de banco ou do PG_DUMP, onde eu possa liberar
mais memoria para o mesmo? Quando
ocorre esse erro o servidor ainda tem cerca de 4GB de ram livre.
Sim (vide acima). Aconselho ler sobre gerenciamento de memória do Windows [1]
e toda a série indicada.
Ou sera que pode ser uma limitação da versão 8.4 ?
Não há tal limitação.
[1] http://blogs.technet.com/b/markrussinovich/archive/2008/07/21/3092070.aspx
--
Euler Taveira de Oliveira - 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] Desorganização do fonte depois de compilar a view e lentidão na execução
On 01-03-2012 16:45, Fábio Naspolini wrote: Trabalho atualmente com o PG 9.1 e já sofri algumas vezes por conta disso, tive uma situação certa vez em que o postgre colocou um cast numa comparação que fez um SQL de poucos segundos demorar mais de 10 minutos (Isso porque cancelei a execução e não esperei até final), novamente hoje me deparei com o mesmo problema. Cadê os planos de execução com a visão e sem ela provando o ocorrido? Gostaria de saber se há como desativar esta reorganização de fontes feita automaticamente pelo postgre? O PostgreSQL não guarda o comando de construção da visão. Se quiser mantê-la alinhada, tenha a mesma armazenada fora do PostgreSQL. Na próxima versão (9.2), o alinhamento do código já está um pouco melhor. Quanto a lentidão, com certeza isso não é por causa das conversões (aka casts). Sem os planos de execução fica difícil apontar uma possível causa. -- Euler Taveira de Oliveira - 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] RES: Dúvida sobre permissões
On 24-02-2012 07:06, Rubens José Rodrigues wrote: Aí é que está! Mesmo eu não informando ordinariamente as permissões ou seja apenas usando o atributo superuser do grupo_suporte e do usuário_super, e ao entrar no psql exemplo e tentar um select em qualquer tabela, recebo a informação de ...denied Você está confundindo permissões com atributos (vide o manual [1]). Atributos [2] (por ex., superuser, createrole, createdb não são herdados); permissões [3] podem ser (vide [4]). b) Na linha 48, eu coloquei o papel usuario_super como membro para grupo_super, logo, ele não deveria herdar as permissões do papel grupo_super? Sim. Não. Não confundam atributos com permissões. Eu desejo associar a vários grupos um usuário de uma única vez, porém com o comando alter role xxx set role yyy somente permite uma única associação pelo menos é que eu percebi na prática. Vide comando GRANT [3]. O comando é: GRANT ROLE foo TO bar. [1] http://www.postgresql.org/docs/current/static/user-manag.html [2] http://www.postgresql.org/docs/current/static/role-attributes.html [3] http://www.postgresql.org/docs/current/static/sql-grant.html [4] http://www.postgresql.org/docs/current/static/role-membership.html -- Euler Taveira de Oliveira - 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] Erro acentuação - xmlattributes
On 23-02-2012 21:07, veronica almeida wrote: teste nome=ver#xF4;nica/ esperava que retornasse teste nome=verônica/ Isso não é um erro; é uma exigência da especificação do SQL/XML. -- Euler Taveira de Oliveira - 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] conexão no windows 7 do cliente não funciona
On 23-02-2012 22:49, vossistemas wrote: pelo jeito não tem solução ou troco de sistema operacional ou troco de banco de dados Quais são as linhas descomentadas do seu pg_hba.conf? As que você postou estão incorretas. Há alguma mensagem no log? Se não for isso, o seu problema é algum software (firewall?) que está bloqueando o acesso a porta do serviço (geralmente a 5432). -- Euler Taveira de Oliveira - 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] Chave Primaria em VARCHAR
On 17-02-2012 12:10, Guimarães Faria Corcete DUTRA, Leandro wrote: 2012/2/17 Euler Taveira de Oliveira eu...@timbira.com: Apostaria alguns centavos que o CHAR é um pouco mais lento do que o VARCHAR. Sério? Por quê, e seria relevante em que escala de operações? Naquelas operações cuja cadeia de caracteres armazenadas é menor do que n (em CHAR(n)). Isso por conta de ter que fazer o preenchimento com espaços. -- Euler Taveira de Oliveira - 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] parada do banco de dados
On 16-02-2012 09:01, Pedro B. Alves wrote: é assim que termina o arquivo de log do dia anterior. Não... procure por mensagens FATAL ou PANIC. Sugiro que atualize imediatamente; a versão 8.2 não é suportada pela comunidade já a alguns meses. -- Euler Taveira de Oliveira - 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] parada do banco de dados
On 15-02-2012 13:12, Pedro B. Alves wrote: 2012-02-15 14:07:14 LOG: database system was interrupted at 2012-02-15 14:05:43 2012-02-15 14:07:14 LOG: checkpoint record is at 0/859989F8 2012-02-15 14:07:14 LOG: redo record is at 0/859989F8; undo record is at 0/0; shutdown FALSE 2012-02-15 14:07:14 LOG: next transaction ID: 0/378462; next OID: 1350407 2012-02-15 14:07:14 LOG: next MultiXactId: 1; next MultiXactOffset: 0 2012-02-15 14:07:14 LOG: database system was not properly shut down; automatic recovery in progress Um desligamento imediato (pg_ctl stop -m immediate)? O que vem antes no arquivo de log ou no arquivo de log anterior? -- Euler Taveira de Oliveira - 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] conexão no windows 7
On 15-02-2012 23:30, Flavio Henrique Araque Gurgel wrote: A linha foi original provavelmente ignorada pelo PostgreSQL. A linha *não* é ignorada; ele (pg_ctl) ignora (aka não executa) o reload (se o serviço estiver executando) ou o início (se o serviço estiver parado). A seguinte mensagem aparecerá no log no primeiro caso: LOG: fim de linha antes do método de autenticação CONTEXTO: linha 94 do arquivo de configuração /a/data912/pg_hba.conf AVISO: pg_hba.conf não foi recarregado -- Euler Taveira de Oliveira - 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] Select into variavel tipo tabela temporaria para iterar depois - sem array
On 14-02-2012 08:05, Moisés P. Sena wrote: Como faço para conseguir o seguinte resultado em uma PL/PGSQL (sem usar ARRAY): a) Selecionar varias linhas e guardar em uma variavel b) iterar sobre as linhas desta variavel e fazer alguma coisa b) iterar novamente as linhas desta variavel e fazer alguma outra coisa Utilize cursor [1]. Não traga os velhos hábitos de linguagens de programação para PLs. [1] http://www.postgresql.org/docs/current/static/plpgsql-cursors.html -- Euler Taveira de Oliveira - 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] Colunas em subQuery
On 10-02-2012 07:57, Kévio Castro wrote: Existe grande diferença de desempenho entre estas duas querys ? O custo de execução da primeira é maior do que a segunda. -- Euler Taveira de Oliveira - 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] Mensagem out of memory for result query
On 09-02-2012 11:12, Tulio Santos wrote: Fiz uma consulta grande no banco e recebi a mensagem out of memory for result query. Isso não tem a ver com work_mem. O problema é na aplicação cliente (qual é?) que está utilizando pois essa mensagem (correto é: out of memory for query result) vem da libpq. Parece-me que a aplicação cliente não consegue alocar memória suficiente para abrigar todos os dados recebidos. Talvez haja algum limite para usuário que executa a aplicação ou a memória da máquina que executa a aplicação não tem memória suficiente mesmo. -- Euler Taveira de Oliveira - 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] Digest pgbr-geral, volume 38, assunto 24
On 08-02-2012 12:21, Sebastião Fidêncio wrote: Só que eu perguntei prá vocês quanto a solução, porque eu tenho comigo que muitas pessoas aqui tem experiência e sabe o que implementou, ou seja, com responsabilidade sabe dizer se X funciona ou não, foi por isso que perguntei, não que eu queira que os Srs. me dê mão beijada as informações para montar tal solução, pelo contrário, sempre fui Autodidata, só que o maior número de informações que eu conseguir obter, vai ser melhor prá mim certo?. e com certeza irei compartilhar convosco possiveis enventualidades que ocorrer durante o processo, tudo bem agradeço pela atenção, e muito obrigado!!! *Nunca* responda a lista com emails resumo (aka digest). Isso bagunça o histórico da lista. AFAICS todos os softwares apontados funcionam mas isso vai depender dos requisitos de sua solução. Vide [1]. [1] http://listas.postgresql.org.br/pipermail/pgbr-geral/2012-January/029055.html -- Euler Taveira de Oliveira - 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] Versao de Banco Bytea para Varchar
On 06-02-2012 10:06, KM wrote:
Qdo executo este SELECT cast(CAST('AMÉRICA' as bytea) as varchar(5000)) ele me
Retorna AM\311RICA
E era para retornar 'AMÉRICA'? Não! Uma vez convertido para bytea o SGBD não
pode adivinhar em qual codificação os dados estão. Para isso o PostgreSQL tem:
euler=# select convert_from(CAST('AMÉRICA' AS bytea), 'utf8');
convert_from
--
AMÉRICA
(1 registro)
Substitua a codificação 'utf8' pela codificação original dos dados.
--
Euler Taveira de Oliveira - 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] Dúvida Modelagem : papéis/usuários x associação com entidades
On 02-02-2012 09:55, Rubens José Rodrigues wrote: Associar um papel/usuário do PostgreSQL a uma entidade Pessoa Clientes, Fornecedores, Funcionários etc..., nosso DBA principal, insiste na idéia de que ele criaria uma entidade usuários, onde a cada criação, alteração ou exclusão ele replicaria e associaria essa informação com os papéis do banco. Eu insisti em dizer que no meu ponto de vista, poderíamos associar a pg_shadow a essa entidade. Não. Você não pode criar chaves estrangeiras no catálogo do sistema. E, pg_shadow não existe (como tabela do catálogo) mais desde o 8.1; é apenas uma visão. Faça um mapeamento entre roles e entidade pessoa, ou seja, faça ações simétricas (INSERT pessoas - CREATE ROLE, GRANT ROLE, UPDATE pessoas - ALTER ROLE(?) e DELETE pessoas - DROP ROLE). Como foi dito acima, crie perfis (aka role) com os diversos níveis de acesso do sistema e atribua as determinadas pessoas no ato da criação (isso irá facilitar o gerenciamento das permissões e roles). -- Euler Taveira de Oliveira - 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] Dúvida Modelagem : papéis/usuários x associação com entidades
On 02-02-2012 12:24, Guimarães Faria Corcete DUTRA, Leandro wrote: 2012/2/2 Euler Taveira de Oliveira eu...@timbira.com: Não. Você não pode criar chaves estrangeiras no catálogo do sistema. E, pg_shadow não existe (como tabela do catálogo) mais desde o 8.1; é apenas uma visão. Euler, não se pode criar chaves estrangeiras para o catálogo do sistema, ou para visões? Catálogo, não. Pela mesma razão, gatilhos no catálogo não são permitidos (na verdade ao criar uma chave estrangeira, você está criando um gatilho para verificá-la em tempo de execução). De qualquer maneira, são limitações arbitrárias. Limitações de implementação (por razões de performance, modificações no catálogo são feitas diretamente -- sem lidar com SQL). Você abriria uma lata de vermes se o fizesse atualmente e, com certeza, modificações no catálogo seriam bem mais lentas. -- Euler Taveira de Oliveira - 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] Instalar pltcl no Centos6 com Pg 9.1.1
On 02-02-2012 14:45, Tulio Santos wrote: Bom.. agora o cenario mudou.. rs (mudei o titulo do assunto..) Mudou o assunto mas sequestrou a thread. Da próxima vez, não clique em 'Responder' e troque o assunto/mensagem. Crie um novo email. O histórico agradece. pode haver algum problema por nao ser a versão 9.1.1 ? Pode. Se houver alguma correção de bugs na PL/Tcl. Copie a versão do repositório [1]. [1] http://yum.pgrpms.org/packages.php -- Euler Taveira de Oliveira - 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] Dúvida Modelagem : papéis/usuários x associação com entidades
On 02-02-2012 12:51, Guimarães Faria Corcete DUTRA, Leandro wrote: Então são duas limitações sobrepostas: catálogo *e* visões? *ou*. No Oracle, eu fazia isso sem maiores dores de cabeça. No catálogo eu até entendo que seria plausível mas em visões? Visões nem mesmo tem restrições! Não estou dizendo que seria impossível mas me parece que seria mais uma gambiarra. -- Euler Taveira de Oliveira - 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] Dúvida Modelagem : papéis/usuários x associação com entidades
On 02-02-2012 20:23, Leandro Guimarães Faria Corce DUTRA wrote: Le 2012-F-2 16h50, Euler Taveira de Oliveira a écrit : On 02-02-2012 12:51, Guimarães Faria Corcete DUTRA, Leandro wrote: Então são duas limitações sobrepostas: catálogo *e* visões? *ou*. Já que sou lesado, traduzo em miúdos: não se podem criar restrições de integridade nem no catálogo, nem em visões. No caso, é uma visão no catálogo, portanto as duas limitações se aplicam. No catálogo eu até entendo que seria plausível mas em visões? Visões nem mesmo tem restrições! Mas não é justamente o que discutimos? A possibilidade de declarar restrições… Coloquialmente, eu definiria visão como nomear uma consulta. Como seria ter restrições (de integridade) em uma consulta (aka visão)? Não estou dizendo que seria impossível mas me parece que seria mais uma gambiarra. Gambiarra por quê? Exatamente como no caso do catálogo, está previsto no modelo e é útil, como demonstra o caso ‘em tela’ (como gostam de dizer no governo…) E o Oracle faz, embora isso não seja um bom argumento… Como criar uma restrição na coluna abc da visão abaixo? CREATE VIEW foo AS SELECT a, CASE WHEN b * c = 2 THEN 10 ELSE 20 END AS abc FROM bar WHERE d 123; Você precisa de pelo menos uma restrição de unicidade para conseguir relacionar com a visão foo (criar uma chave estrangeira na coluna abc da visão foo). Assim, não vejo como fazer isso sem muita complexidade (na linguagem SQL) e esforço (que não vale a pena no momento -- temos muitas coisas mais interessantes para implementar do que isso). -- Euler Taveira de Oliveira - 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] Instalar plpythonu
On 01-02-2012 11:04, Tulio Santos wrote: Tenho que criar uma função que usará a linguagem Python.. No entanto executando no postgres CREATE LANGUAGE plpythonu; obtive o retorno.. ERRO: não pôde acessar arquivo $libdir/plpython: Arquivo ou diretório não encontrado O pacote que você precisa é o postgresql-plpython e não PyGreSQL. -- Euler Taveira de Oliveira - 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] Transações
On 01-02-2012 23:16, Ronei Heck wrote: Pode ser um problema do clarion, ou a maneira como estou programando. Alguma idéia do que pode ser? É o que parece. Ele deve estar no modo auto-efetivação (aka autocommit). Para tirar a prova, habilite o log de todas as consultas (log_min_duration_statement = 0) e teste sua aplicação. -- Euler Taveira de Oliveira - 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] Campo double precision
On 30-01-2012 07:44, Emanuel Araújo wrote: O comando que estou fazendo é a partir de um host postgreSQL 91: pg_dump -h pg84 db01 -Fc -b -v | pg_rstore --disable-triggers -v -i -d db01_mig Tente fazer a cópia utilizando o pg_dump da 8.4 ao invés da 9.1. -- Euler Taveira de Oliveira - 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] Diferença de hora entre o Windows e o Postgresql nele instalado
On 30-01-2012 10:13, Leandro Guimarães Faria Corce DUTRA wrote: Le 2012-J-30 09h5, Flavio Henrique Araque Gurgel a écrit : O timezone do PostgreSQL é independente do sistema operacional. Nem sempre. Ele pode ser dependente se você utilizar --with-system-tzdata. Acho que isso já foi discutido aqui, mas… por quê? O PostgreSQL permite que você utilize a zona horária do SO ou a sua própria. Caso você não tenha controle (seja administrador), mesmo assim você poderá utilizar as regras de zonas horárias atuais (desde que consiga atualizar a instalação do PostgreSQL -- por exemplo, 9.0.1 - 9.0.2). -- Euler Taveira de Oliveira - 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] Diferença de hora entre o Windows e o Postgresql nele instalado
On 30-01-2012 13:23, Guimarães Faria Corcete DUTRA, Leandro wrote: 2012/1/30 Euler Taveira de Oliveira eu...@timbira.com: On 30-01-2012 10:13, Leandro Guimarães Faria Corce DUTRA wrote: Le 2012-J-30 09h5, Flavio Henrique Araque Gurgel a écrit : O timezone do PostgreSQL é independente do sistema operacional. Nem sempre. Ele pode ser dependente se você utilizar --with-system-tzdata. Ah, obrigado por refrescar nossa memória, Euler! O PostgreSQL permite que você utilize a zona horária do SO ou a sua própria. Caso você não tenha controle (seja administrador), mesmo assim você poderá utilizar as regras de zonas horárias atuais (desde que consiga atualizar a instalação do PostgreSQL -- por exemplo, 9.0.1 - 9.0.2). Complexidade, complexidade… Flexibilidade. Existem ambientes em que você executa um serviço mas não tem os poderes de Grayskull. -- Euler Taveira de Oliveira - 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] Campo double precision
On 28-01-2012 09:23, Emanuel Araújo wrote: So: CentOS (dump) - Redhat (restore) Desconfio que o problema seja sua plataforma e não o PostgreSQL. Qual a saída de select version() de ambas as máquinas? Qual o comando utilizado para fazer a cópia no CentOS? -- Euler Taveira de Oliveira - 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] Listar Transações
On 27-01-2012 08:26, Aldrey Galindo wrote: Na versão 8.4.5 há como tentar ver algo? Tem alguma sugestão? Uma maneira é garimpar os logs. Se você não utiliza pool de conexões ou conexões persistente, os seguintes passos podem te ajudar. Habilite a gravação dos comandos (log_min_duration_statement = 0) e inclua o PID, session id e session line number (log_line_prefix). Encontre uma transação 'idle in transaction' e obtenha o PID (em pg_stat_activity). Vá aos logs e siga pelo session id e session number quais foram os comando executados e a sua ordem. Vá até a aplicação e identifique o caminho que gerou aquela sequência de comandos. Por fim, corrija a aplicação. PS já estamos na 8.4.10. Atualize a sua versão. -- Euler Taveira de Oliveira - 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] Banco de dados não inicia serviço
On 27-01-2012 14:08, Ronei Heck wrote: O último log existente, do dia que deu problema está a seguir. Hoje não está criando novos logs. Você não entendeu... Qual o log gerado se você coloca o diretório global que tem no agrupamento de dados corrompido e inicia o PostgreSQL? -- Euler Taveira de Oliveira - 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] Listar Transações
On 26-01-2012 18:35, Aldrey Galindo wrote: Fiquei com uma dúvida recente em relação a 'idle in transaction'. Tem como eu obter que transação é essa? Saber quando ela foi iniciada, quem foi, etc? Posso fazer log pra identificar quem dessas transações está demorando? Sugestões? Atualmente não mas com as mudanças recentes no pg_stat_activity haverá a partir do 9.2. Quando e quem você pode obter no pg_stat_activity. Rastrear a transação que está causando 'idle in transaction', às vezes, não é uma tarefa simples (principalmente se o volume de transações e a quantidade de funcionalidades são altos). -- Euler Taveira de Oliveira - 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] Banco de dados não inicia serviço
On 25-01-2012 13:53, Ronei Heck wrote: 2011-12-25 19:57:59 BRT PANIC: could not fsync control file: Bad file descriptor O arquivo $PGDATA/global/pg_control existe? -- Euler Taveira de Oliveira - 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] Banco de dados não inicia serviço
On 25-01-2012 15:07, Ronei Heck wrote: Verificando aqui, na minha pasta \data que funciona normalmente, tem uma pasta global e o arquivo pg_control, mas na pasta do meu cliente que não abre, não tem a pasta global. O que isto indica? Indica de informações essenciais para o início do banco de dados estão faltando. Você tem certeza que o diretório global não existe? Isso é bizarro mas se tratando do SO que está utilizando não podemos esperar muita coisa. É muito difícil reconstruir o banco de dados sem conhecer as tabelas globais do sistema (como pg_database e pg_authid) e informações sobre o status das transações. -- Euler Taveira de Oliveira - 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] Incomplete startup packet
On 24-01-2012 15:37, Tulio Santos wrote: Utilizamos o Zabbix para monitoramento... Esse tipo de problema é comum no uso dessa ferramenta? Não é uma boa prática fazer isso para verificar se o PostgreSQL está vivo mas ... se bem que alguém poderia mudar isso para algo mais inteligente (como por exemplo, o PQping() que infelizmente só está disponível a partir da 9.1). -- Euler Taveira de Oliveira - 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] Balanceamento de carga com PostgreSQL 9.1
On 19-01-2012 13:54, Eric Patrick wrote: Realmente Flávio, fiz muitas perguntas em um email só. Mas o problema é o seguinte: Tenho um colega trabalhando na configuração do pgpool e ele está tendo alguns problemas, a minha intenção era investigar uma outra forma de realizar o balanceamento e o failover, visto que o pgpool tem tomado muito tempo na configuração. Quais os problemas? Identifique-os. Tenha em mente que antes de substituir uma solução, você deve identificar quais os requisitos _não_ são atendidos pela solução atual; a partir daí, procurar soluções que atendem a esses requisitos. Soluções de balanceamento e _failover_ são bem mais complexas quando estamos falando de banco de dados. O pgpool-II é uma solução bastante utilizada para tal função. Mas sem conhecer o seu cenário fica difícil indicar outra alternativa. Soluções como streaming replication + hot standby, Slony-I, Bucardo, PL/Proxy + PGBouncer, pyReplica, rubyrep dentre outros podem ser uma possível solução. -- Euler Taveira de Oliveira - 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] Consultar numero de transações
On 19-01-2012 12:42, Flavio Henrique Araque Gurgel wrote: 1º valor obtido.. F/7D13E1A8 = 2.098.454.952 2º valor obtido.. F/7D286F18 = 2.099.801.880 Diferença de 1.346.928 transações? Correto. Transações virtuais (xID). Ugh? Estamos falando de pg_current_xlog_location(), certo? Neste caso, estamos falando de valor em *bytes*. Para entender o que significa o valor retornado, sugiro que leia [1]. No caso acima, temos 1.346.928 bytes (~ 1,3 MB), ou seja, em 1 minuto foi gerado essa quantidade de log de transação. Sobre transações, vide as funções em [2]. [1] http://eulerto.blogspot.com/2011/11/understanding-wal-nomenclature.html [2] http://www.postgresql.org/docs/current/static/functions-info.html#FUNCTIONS-TXID-SNAPSHOT -- Euler Taveira de Oliveira - 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] Consultar numero de transações
On 19-01-2012 17:25, Fabrízio de Royes Mello wrote: E se precisar calcular a diferença em bytes do xlog da replica e do master (lag), pode usar as funções: -- Convert from HEX to INT CREATE OR REPLACE FUNCTION hex2int(TEXT) RETURNS bigint AS Só um comentário que ainda não postei no blog... Fiz uma função [1] que deve fazer parte do 9.2 justamente para fazer esse cálculo. Quanto a sua função, acho que ela deveria retornar numeric ao invés de bigint porque você corre o risco de overflow. [1] https://commitfest.postgresql.org/action/patch_view?id=776 -- Euler Taveira de Oliveira - 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] erro na configuração do pgpoolAdmin
On 16-01-2012 21:16, Antonio Abner Junior wrote: Mesmo realizando o procedimento, quando vou realizar as verficações no pgpoolAdmin(php) me mostra a mensagem de direitos de escrita negados para os arquivos pcp.conf e pgpool.conf. Mesmo depois de aplicar o chmod 777 nos arquivos, ainda o erro persiste. Será algum bug, alguém poderia ajudar ? Certamente é problema de permissão no diretório /usr/local/etc. -- Euler Taveira de Oliveira - 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] Postgres 9.1
On 13-01-2012 16:51, Irineu wrote: Estou usando a versão 9.0, vale a pena migrar para 9.1 ? É sempre recomendável atualizar. Toda nova versão apresenta melhorias mas também introduz incompatibilidades. Homologue os seus sistemas antes de fazer a migração. Leia as notas de lançamento [1] para saber quais são as melhorias e incompatibilidades. [1] http://www.postgresql.org/docs/current/static/release-9-1.html -- Euler Taveira de Oliveira - 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] OFF-TOPIC - Vaga para DBA PostgreSQL
On 10-01-2012 09:47, Eduardo Santos wrote: Mais uma reflexão para fomentar a discussão: que mal tem criar a lista de vagas? Não haveria uma necessidade grande de armazenamento ou algo assim, apenas uma lista de e-mail para divulgar as vagas. Isso já foi discutido e rejeitado no passado. IMO a demanda é muito pequena para criação de uma lista. Não vejo problemas que as vagas sejam postadas aqui; havendo abusos os moderadores desta lista irão agir. É claro que o questionamento/dúvidas sobre as vagas devem ser feitos fora da lista. -- Euler Taveira de Oliveira - 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] SQL Da certo no pgAdmin mas não no delphi
On 09-01-2012 07:48, Paulo Nievierowski wrote: A solução para ZEOS é duplicar os '::' =' ' Em vez de duas vezes dois pontos, use quatro vezes dois pontos. Também para ' $ ' use ' $$ '. Se isso for verdade, é um bug no Zeos e deve ser reportado. Mexer em uma consulta com caracteres de escape para a biblioteca entender é inadmissível. -- Euler Taveira de Oliveira - 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] IDE gerenciamento BD para linux (off-topic)
On 04-01-2012 15:07, Flávio Alves Granato wrote: Acho que a moderação não deveria tolerar este tipo de discussão porque agora vai ter réplica e tréplica eternos... FYI, os moderadores desta lista tentam conter os excessos. Vide [1]. [1] http://listas.postgresql.org.br/pipermail/pgbr-geral/2012-January/028874.html -- Euler Taveira de Oliveira - 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] IDE gerenciamento BD para linux
On 04-01-2012 12:38, Shander Lyrio wrote: Pensando bem, eu nunca pude fazer uma doação direta para o PostgreSql, sempre faço para a SPI (Software in the Public Interest, Inc.), logo parte do meu dinheiro está sendo usada para financiar também o PgAdmin. Se você doar para SPI _sem_ escolher o projeto PostgreSQL, na verdade, você está doando para todo o pool de projetos da SPI (no qual o PostgreSQL está incluso). Além disso, você *não* está doando dinheiro para o pgAdmin, pois ele é um projeto a parte. Alias, porque não responde ao tópico ao invés de me agredir diretamente. Discutam o sexo dos anjos fora da lista, por favor. -- Euler Taveira de Oliveira - 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] Memoria Windows
On 29-12-2011 15:35, Andre Avila wrote: Estou fazendo testes de memoria do postgesql no windows, porem notei que em computadores com windows seven estou tendo um desempenho melhor que no windows 2003 sevver ...isso teria fundamento ?? Você está comparando laranja com laranja, digo, é o mesmo hardware? Que tipo de benchmark está fazendo? Você está considerando o efeito da cache? Qual a versão do PostgreSQL está sendo testada? É a mesma em ambas as máquinas? Como você não disse qual win2k3 (existem várias edições) está testando, só ressalto que o mesmo já tem 8 anos de estrada enquanto o win7 só tem 2. -- Euler Taveira de Oliveira - 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] Distribuição em discos
On 28-12-2011 13:59, Fábio Gibon - Comex System wrote: sem uma análise muito profunda, uma instalação de um cluster usando 3 discos (um para os WAL, outro para as tables e um último para os indexes) estaria no caminho do ideal? A pergunta carece de dados do cenário mas sendo direto: do ponto de vista de performance, sim; do ponto de vista de segurança dos dados, não. -- Euler Taveira de Oliveira - 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] Distribuição em discos
On 28-12-2011 14:35, Fábio Gibon - Comex System wrote: você considera inaceitável um banco de produção não estar com o archive_mode ativo? [O assunto mudou mas...] Isso vai depender da estratégia de cópia de segurança utilizada e da disponibilidade do serviço. Se esses 2 itens tem um peso no seu cenário, minha resposta é sim. -- Euler Taveira de Oliveira - 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] Variavel especial $? vs pg_dump
On 20-12-2011 14:02, Tiago Valério wrote: Estou usando no shell script a variavel $? para verificar o sucesso ou insucesso da execução do restore, porem como estou executando com -c alguns objetos no meu banco hospedeiro não existem logo o restore gera um erro causado pelo proprio -c ao tentar dropar algum objeto que nao existe.Porem isto esta refletindo nesta variavel especial $? o que indica que isto como um erro. Pergunto, existe outa forma avaliar a execução do pg_restore? Faça a restauração em um banco de dados recém criado. -- Euler Taveira de Oliveira - 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] Mudar tipo de dados.
On 16-12-2011 13:23, l...@xharbour.com.br wrote: Porque vc quer mudar de double para numeric, se fizer isso, vc pode ter perda de dados Acho que você se confundiu (vide [1]). numeric possui uma precisão muito maior do que double precision. Além disso, o cálculo com tipo numeric não sofre de problemas de arredondamento como no tipo double precision. [1] http://www.postgresql.org/docs/current/static/datatype-numeric.html#DATATYPE-FLOAT -- Euler Taveira de Oliveira - 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] Auxilio com dll contrib lo.dll
On 12-12-2011 16:53, Bruno Moreira wrote: Eu primeiramente tenter refazer os cast implicitos apontando para a dll lo.dll da versão 8.0 mas eu recebia uma informação que está dll não possuia na sua copilacao o importe de PG_MODULE_MAGIC;. Utilize as funções da última versão antes da retirada dos casts (no branch REL8_2_STABLE). Fiz isso e estou com o fonte do meu Frankstain lo.c pronto mas não consigo compilacao utilizando turco c++ e outros compiladores c que encontramos na internet. Utilize o gcc no *nix, o MSVC (2005, se não me engano) no Windows. Alguem sabe como em windows ou linux eu posso compilar essa minha nova lo.c e que esta consiga entender os includes do projeto afim que eu consiga que minha lo.c compile e gere minha lo.dll ? Vide [1] para dicas como compilar uma extensão no Linux. Realmente preciso fazer essa nova lo.dll ou existe alguma outra alternativa para poder criar meu cast implicito para o tipo lo de forma implicita ? Não. Tenha em mente que recriar casts é algo temporário. O ideal é alterar a aplicação para não depender deles. sei que estou sendo chato,mas realmente não estou conseguindo tirar essa pedra do meu caminho.Preciso conseguir sair da versão 8.0 do postgres sem depender muito da boa vontado dos meus amigos do desenvolvimento do ERP da empresa de onde eu trabalho. Acho melhor você planejar com a equipe e explicar que a versão 8.0 já foi descontinuada a mais de 1 ano e que qualquer bug presente naquela versão *não* será corrigido. [1] http://www.timbira.com/presentations/pgconbr_2009/extensao_c.pdf -- Euler Taveira de Oliveira - 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] Cronograma de descotinuação.
On 14-12-2011 19:02, Targino Silveira wrote: Boa noite senhores, vocês sabem informar se existe um cronograma de descontinuação das versões do postgre? Postgres. Você terá um pouco mais do que 1 ano [1]. [1] http://wiki.postgresql.org/wiki/PostgreSQL_Release_Support_Policy -- Euler Taveira de Oliveira - 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] PostgreSQL no Windowns XP - problema de permissão
On 14-12-2011 00:23, Fabiano Donato wrote: Olá Depois de vários dias tentando instalar o PostgreSQL e varrer os fóruns à procura de pistas para meu problema... estou quase jogando a toalha... :-) Vou resumir assim (para ser objetivo): Nem sempre resumir ajuda. Se não conseguir resolver com a dica abaixo, tente olhar algumas dicas em [1] (slides 10-13) para tentar solucionar o problema. - bem, o arquivo LOG só é gerado quando instalo pelo instalador. O erro é, aparentemente, tentativa de escrita na partição DATA. É onde dá erro e a instalação é interrompida; Você não mostrou o erro no final do arquivo bitrock_installer*.log Além disso, faltou informar se tem algum antivírus ou anti-algumacoisa instalado. Se tem, já tentou *removê-lo* (não, desabilitar algumas vezes não funciona)? [1] http://www.timbira.com.br/materiais/tudo-o-que.pdf -- Euler Taveira de Oliveira - 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] BRTFATAL: terminando conexão por causa de um comando do administrador
On 07-12-2011 09:05, jorge augusto soares wrote: Vou relatar melhor o caso. O postgresql está instalado em um datacenter com vários bloqueios, windowns server 2008. Pelo que eu procurei na internet fala que o usuário administrador deu um kill no processo. Olhei o log do win2008 mas não tem acesso de nenhum usuário nesse horário para dar um kill e também não registra nenhum log anormal do windows. To no desespero, como vou dizer que o banco parou sozinho, acaba com a confiança. Você não disse a versão do PostgreSQL mas espero que seja uma versão suportada (= 8.3). Quanto a parada do serviço, às 08:59:58 há várias mensagens indicando que o mesmo foi parado; se não foi você deve ter sido outro administrador? Esse erro da direto: 2011-12-03 07:00:02 BRTLOG: EOF inesperado durante conexão do cliente 2011-12-03 07:00:39 BRTLOG: EOF inesperado durante conexão do cliente Esse erro é porque a aplicação está sendo fechada abruptamente (exemplo mais commum disso é quando a aplicação trava e o usuário força o fechamento da mesma). Revise a sua aplicação, provavelmente é ela que está causando isso. -- Euler Taveira de Oliveira - 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] pg_resetxlog
On 06-12-2011 19:14, Fábio Gibon - Comex System wrote: [Gibon] Flávio, tentei fazer isto, mas ao fazer o dump eu recebi outra mensagem de erro (e isto já aconteceu comigo em outras duas situações que usei o pg_resetxlogs) e acabei não conseguindo voltar a base e então tive que usar o dump. O erro no momento do novo dump foi: cabeçalho de página é inválido no bloco 147859 da relação /base/16393/769035. Alguma dica porque isto aconteceu? O arquivo do banco também estava corrompido? Porque o disco corrompeu o arquivo 769035 também. -- Euler Taveira de Oliveira - 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] pg_resetxlog
On 06-12-2011 19:24, Leandro Guimarães Faria Corce DUTRA wrote: Le 2011-D-6 21h13, Fábio Gibon - Comex System a écrit : Porque o disco corrompeu o arquivo 769035 também. O disco ou (principalmente em se tratando de MS Windows) o sistema de arquivos. Não se sabe. O que mais tenho visto são máquinas com componentes de qualidade péssima ou, no mínimo, duvidosa que falham após algum tempo. Cada um põe os ovos naquele cesto que se sente seguro. -- Euler Taveira de Oliveira - 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] Colunas da function concatenadas nas colunas do select
On 05-12-2011 09:34, Thiago wrote: Depois tentei da seguinte forma: select pr.* from public.tb_produtos pr left join functions.sp_estoque_demanda(pr.codigo) sp on pr.codigo = sp.r_cod Especifique a lista de colunas da saída da função assim: sp_estoque_demanda(pr.codigo) as sp(r_est integer, r_dem integer, bar float) -- Euler Taveira de Oliveira - 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] Colunas da function concatenadas nas colunas do select
On 05-12-2011 11:57, Thiago wrote: Euler, fiz da forma que me recomendou, utilizando um join, porém ainda está aparecendo a seguinte mensagem de erro: There is an entry for table pr, but it cannot be referenced from this part of the query. Ugh? Qual a consulta utilizada? E a assinatura da função? -- Euler Taveira de Oliveira - 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] Colunas da function concatenadas nas colunas do select
On 05-12-2011 12:37, Thiago wrote: On 5/12/2011 13:04, Euler Taveira de Oliveira wrote: On 05-12-2011 11:57, Thiago wrote: Euler, fiz da forma que me recomendou, utilizando um join, porém ainda está aparecendo a seguinte mensagem de erro: There is an entry for table pr, but it cannot be referenced from this part of the query. Ugh? Qual a consulta utilizada? E a assinatura da função? Consulta: select * from public.tb_produtos pr left join public.sp_est_dem(pr.codigo) as sp(r_codigo,r_est,r_dem) on pr.codigo = sp.r_codigo ^ Você não pode usar pr.codigo aqui. Acho que você algo como: select pr.*, (public.sp_est_dem(pr.codigo)).r_est, (public.sp_est_dem(pr.codigo)).r_dem FROM public.tb_produtos pr; Função: CREATE OR REPLACE FUNCTION public.sp_est_dem ( p_codigo integer, out r_codigo integer, out r_est integer, out r_dem inet ) RETURNS SETOF record AS Mas a assinatura deve substituir 'SETOF record' por 'record'. -- Euler Taveira de Oliveira - 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] Identificar Chaves Estrangeira que não possuem indices.
On 02-12-2011 15:46, JotaComm wrote: SELECT pg_class.relname AS Nome da tabela, pg_attribute.attname AS Nome do atributo, pg_constraint.conname AS Nome da restrição - Chave estrangeira, pg_indexes.indexname AS Nome do índice, pg_indexes.indexdef AS Definição do índice FROM pg_class JOIN pg_namespace ON pg_class.relnamespace=pg_namespace.oid JOIN pg_attribute ON pg_class.oid=pg_attribute.attrelid JOIN pg_constraint ON pg_attribute.attnum=ANY(pg_constraint.confkey) AND pg_class.oid=pg_constraint.conrelid LEFT OUTER JOIN pg_indexes ON pg_class.relname=pg_indexes.tablename WHERE pg_namespace.nspname='public'; Essa consulta traz a coluna da chave estrangeira incorreta. confkey é relativo as colunas da tabela referenciada pela chave estrangeira. O correto seria algo com: attnum = ANY(conkey) AND contype = 'f' Além disso, o último LEFT JOIN falha ao obter o nome do índice da coluna em questão; ele está pegando qualquer índice da tabela. O correto seria fazer uma correspondência com attnum (pg_attribute) e indkey (pg_index). -- Euler Taveira de Oliveira - 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] Identificar Chaves Estrangeira que não possuem indices.
On 02-12-2011 17:05, Moisés P. Sena wrote: Criei todos os meus relacionamentos usando ALTER TABLE ADD CONSTRAINT ... sendo que a coluna referenciada é CHAVE PRIMARIA da tabela estrangeira. Mesmo assim vou ter que criar os indices manualmente? Não confunda as coisas. Só porque estamos falando de chave estrangeira não significa que devemos ter índice. No caso de junção entre duas tabelas foo e bar, se bar referencia foo, ou seja, bar tem uma chave estrangeira para foo, o otimizador vai ser esperto o suficiente para usar o índice da tabela referenciada (foo); sendo assim, *não* precisamos de índice em bar. Índices em tabelas que referenciam outras são necessários, quando *não* utilizamos uma junção com a tabela referenciada e estamos utilizando o campo da chave estrangeira na cláusula WHERE. Isso nem sempre é uma máxima em todos os modelos, então tome cuidado ao sair criando um monte de índices inúteis na sua base de dados. O melhor a fazer é avaliar as consultas e saber se alguma delas se encaixa no critério descrito neste parágrafo. -- Euler Taveira de Oliveira - 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] Obter Memoria usada pelo postgres
On 01-12-2011 11:41, Marcone wrote: Aí agora vem a questão: o que é o uso de memória do PostgreSQL? Memória total ou sem levar em conta a memória compartilhada? Do ponto de vista do sistema operacional, é tudo; do ponto de vista das aplicações clientes, somente a memória utilizada nas consultas. Saber a quantidade de memória utilizada em alguns cenários é irrelevante para determinar a eficiência de uso dos recursos pelo SGBD. Isso porque se alguém ajusta (erroneamente) 90% da memória da máquina para a cache do PostgreSQL (aka shared buffers), será que estamos perto de um upgrade de memória? Segundo o sistema operacional, sim; pois em certos momentos pode faltar memória para outras tarefas (até mesmo tarefas do PostgreSQL). Para saber como está o uso de recursos do SGBD, você deve olhar dentro do SGBD e não fora. Existem inúmeros parâmetros e ferramentas para extrair estas informações; alguns deles foram citados nesta discussão. -- Euler Taveira de Oliveira - 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] Truncate, lo_unlink, vacuum full
On 29-11-2011 21:06, Emanuel Araújo wrote: Existe um processo nosso de deleção de oids que ao deletarmos uma determinada quantidade de registros (+oids) de uma tabela, fazemos um lo_unlink do oid. Isso libera o espaço em disco? ou tenho que realmente usar vacuum full e somente ele faz esse trabalho? São coisas diferentes pois o armazenamento é separado. Em uma tabela sem campos oid, o VF devolve o espaço não utilizado. Um campo oid tem o seu armazenamento a parte do(s) arquivo(s) da tabela; portanto se você não utilizar um lo_unlink esse espaço não será reaproveitado a não ser que você execute o vacuumlo. recentemente estava com uma tabela com 40gb de dados e ao fazer um truncate simples da tabela, percebi qe o espaco do disco foi liberado, ótimo para truncar toda a tabela, mas existe uma forma de realizar um truncate condicional? assim como o delete from? Não existe TRUNCATE condicional. Se você quer remover a maioria das tuplas de uma tabela, não utilize DELETE, ao invés disso, utilize CREATE TABLE AS SELECT e substitua a tabela antiga pela nova (você pode até fazer isso dentro de um bloco de transação); é mais rápido se a tabela for grande, tiver muitos índices e chaves estrangeiras. -- Euler Taveira de Oliveira - 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] pgpass
On 22-11-2011 20:27, Marllos wrote: /var/lib/postgresql/.pgpass (proprietario postgres, permissão rw- --- ---) e também em /home/postgres/.pgpass (essa pasta não exitia, eu criei: proprietario postgres, permissão rw- --- ---) local:5433:postgres:postgres:$enha O arquivo .pgpass deve ficar na diretório $HOME do usuário do sistema operacional que executa o script, ou seja, o caminho indicado pelo comando 'echo $HOME'. Quanto ao conteúdo do arquivo, ele deve ser: maquina:porta:bancodedados:usuario:senha A não ser que exista uma máquina chamada 'local' mas acho que você quer dizer 'localhost'. -- Euler Taveira de Oliveira - 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] Arquitetura para Seleção de ìndices
On 21-11-2011 09:52, Bruno Silva wrote: Desculpa, mas isso não seria pra lista -dev ? Não. Da descrição da lista -dev: Lista para organização do PostgreSQL Brasil. Coordenação do site, traduções, eventos e outros projetos. -- Euler Taveira de Oliveira - 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] Chave Primaria, precisa criar indice manualmente?
On 20-11-2011 23:53, Leandro Guimarães Faria Corce DUTRA wrote: Em outros termos, uma chave primária é conceitual; o índice é só um detalhe de implementação, infelizmente fixado no SQL. No SQL, não; o padrão SQL não especifica índices. ... infelizmente fixado no SGBD. -- Euler Taveira de Oliveira - 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] Arquitetura para Seleção de ìndices
On 21-11-2011 10:33, Leonardo Cezar wrote: 2011/11/21 Euler Taveira de Oliveira eu...@timbira.com: On 21-11-2011 09:52, Bruno Silva wrote: Desculpa, mas isso não seria pra lista -dev ? Não. Da descrição da lista -dev: Lista para organização do PostgreSQL Brasil. Coordenação do site, traduções, eventos e outros projetos. Essa não é a primeira vez que se faz confusão e nem será a última. Estou inclinado a mudar o nome da lista de -dev para -org ou -coord. +1 -coord. -- Euler Taveira de Oliveira - 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] problemas instalação 9.1.1-1
On 21-11-2011 10:50, antonio borba wrote: Olá camaradas estou instalando em minha máquina o Postgre 9.1.1-1 WinXP e sempre ao fianl da instalação retorna mensagem de erro. Mensagem? Trecho do arquivo %TEMP%/bitrock_installer*.log contendo detalhes do erro? -- Euler Taveira de Oliveira - 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] backup/restore
On 21-11-2011 22:09, Flavio Henrique Araque Gurgel wrote: Grande Jotinha. Desde a versão 8.4 o pl/pgsql vem disponível por padrão em todos os bancos de dados. Uma pequena correção: 9.0. -- Euler Taveira de Oliveira - 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] [OFFTOPIC] tradução da documentação
On 18-11-2011 12:33, Dickson S. Guedes wrote: [corrigindo o tópico...] Lembro de há uns 3 (três) anos testado algumas possibilidades e uma delas era inclusive gerar um arquivo POT a partir do SGML. Isso seria interessante por questões de centralização pois assim seria possível utilizar uma infra já existente, como um modulo no Drupal em nosso site por exemplo, subir uma aplicação específica como o Pottle ou ainda usar uma infra externa já homologada por outras comunidades, como o Rosetta do Lauchpad, assim centralizando traduções de documentação e de aplicativos. Não vou entrar no mérito dessas ferramentas porque elas facilitam a tradução mas dificultam a revisão. Além disso, em situações particulares, contextos diferentes podem merecer traduções diferentes da mesma sentença. Sou adepto da tradução livre. Fora isso, podemos iniciar com o método mais simples: poderiamos criar um projeto no github por exemplo que aceitaria pull requests para centralizar a documentação. Alias, Euler, o que acha de pegarmos o projeto de documentação que está lá no pgfoundry e colocar no github? Em verdade eu tenho aqui já o projeto importado seria só enviar para lá, e começarmos a contribuir. O fluxograma seria simples ao meu ver. Bem é só uma ideia. O projeto atual está no subversion do p.o.b. Eu poderia migrar os arquivos para o github mas eu preferia tê-los na infra do p.o.b. Neste caso, poderíamos tranquilamente sincronizá-los no github ou outros serviços semelhantes. Ao meu ver o formato SGML permite uma leitura fácil pelos humanos e não deixa de ser um XML, tanto que tem ferramentas que traduzem de um para outro. Por isso não acho que seria um ganho significativo, mas não lembro de ter ouvido os argumentos a favor. Na verdade é o contrário; XML é baseado no SGML. SGML está obsoleto (na verdade, o ferramental dele) e só suporta LATIN* + entities. Para a tradução da documentação, o ideal seria fazer como os franceses e japoneses fazem para traduzir o manual: converter SGML - XML e traduzir o produto final. No entanto, isso não quer dizer que não possamos continuar a traduzir os SGMLs; não necessitamos de UTF8 para traduzir a documentação (como é o caso dos japoneses). IMHO está discussão pertence a -dev. -- Euler Taveira de Oliveira - 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] Serviço do postgres não inicia
On 16-11-2011 11:06, rvgugisch wrote: Alguém teria mais alguma dica para fazer rodar o serviço? Dar permissão no diretório pg_log ao usuário postgres? -- Euler Taveira de Oliveira - 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] Brutal queda de performance atualizando de 8.2 para 8.4
On 12-11-2011 13:05, Eduardo Santos wrote: Desculpe, esqueci de anexar a consulta. É uma consulta realmente feia, mas que não chegava a ser um desastre no banco: Um comentário: o PostgreSQL não se dá muito bem com listas grandes no IN. Os valores vem de outra consulta, se sim, talvez seja prudente substituir esses valores por uma junção. Tabela public.acs_object_context_index Parece-me que está tabela e/ou índice acs_obj_ctx_idx_ancestor_idx está(ão) inchado(s). Faça um VACUUM nessa tabela e um REINDEX no índice mencionado. Verifique se o plano muda. Ela funciona como uma tabela intermediária para facilitar a contagem da quantidade de filhos que determinado objeto tem. É uma tentativa de evitar a contagem num subselect, o que tornaria a consulta ainda mais lenta. Você chegou a testar essa estratégia? Otimização precoce pode ser pior que nenhuma otimização. Sabe me dizer se houve alguma mudança significativa no otimizados entre as versões 8.2 e 8.4? Várias mudanças. Vide notas de lançamento da 8.3 e 8.4. Outra coisa que notei foi que a cardinalidade (aka número de tuplas) das tabelas envolvidas parece ter tamanho diferentes entre as versões. Os bancos de dados são idênticos? Teste as várias estratégias apontadas e apresente os novos planos de consulta. -- Euler Taveira de Oliveira - 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] Postgres Embarcado Existe?
On 09-11-2011 07:48, Marcelo Silva (IG) wrote: Existe Postgres embarcado? Só para ficar claro. Não existe e não existirá (pelo menos em um futuro próximo) um PostgreSQL embarcado -- isto já foi discutido várias vezes na lista e inclusive está na lista de funcionalidades que não queremos. Ah, e banco de dados embarcado [1] é muito diferente de banco de dados distribuído e instalado junto com a aplicação. [1] http://en.wikipedia.org/wiki/Embedded_database -- Euler Taveira de Oliveira - 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] Fwd: Help - Migração do Postgres 8.0 para versão 8.3
On 10-11-2011 10:52, Bruno Moreira wrote: Bom dia. Preciso da ajuda de vocês.Existe algum lugar onde eu consiga descobrir que *cast implicitos* existiam na versão 8.0 que não existem na versão 8.3 . Você pode comparar os catálogos (pg_cast) das duas versões ou ler [1]. Gostaria de tentar re-escrever estas cast implicitos mas não sei como descobrir de forma rápida quais cast implicitos deixaram de existir. Os casts removidos foram aqueles de qualquer tipo de e para tipo text. O aconselhável não é recriar os casts e sim corrigir a aplicação. [1] http://petereisentraut.blogspot.com/2008/03/readding-implicit-casts-in-postgresql.html -- Euler Taveira de Oliveira - 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] Vacuum full - informação de execução
On 08-11-2011 07:51, Leonardo Carneiro wrote: Interessante essa info sobre o vacuum full. Algumas pessoas comentaram durante o pgbr que o vacuum full não deveria ser usado antes da versão 9 sem executar reindex, pois iria ser prejudicial aos índices. Eu não o recomendado desde 7.4. A implementação antiga do VF inchava os índices ao longo do tempo mas a implementação atual não. Existe alguma documentação dessa mudança do funcionamento do VACUUM FULL ser igual ao CLUSTER? É um detalhe de implementação. A única menção que há é nas notas de lançamento da versão 9.0. Vale ressaltar que não é igual, ele utiliza a mesma rotina do CLUSTER para recuperar espaço não utilizado. -- Euler Taveira de Oliveira - 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] Vacuum full - informação de execução
On 07-11-2011 19:55, Fábio Gibon - Comex System wrote: o vacuum com a opção de full não fica registrado na pg_stat_all_tables (em last_vacuum). Há algum local do dicionário de dados que eu encontro a data do último vacuum full de uma tabela? Isso é verdade a partir da versão 9.0 (quando o VACUUM FULL foi substituído por CLUSTER internamente) e está documentado [1]. Talvez algum dia alguém corrija isso mas como o VF é uma operação programada (e esporádica) em um ambiente de produção não vejo problema em não reportar essa estatística (já que sei quando ela é disparada). [1] http://www.postgresql.org/docs/current/static/monitoring-stats.html#MONITORING-STATS-VIEWS-TABLE -- Euler Taveira de Oliveira - 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] Segurança de dados no SGBD
On 01-11-2011 08:36, Flávio Alves Granato wrote: Entendo, mas a solução que você deu não resolve o problema pois por mais que algum funcionário assine um termo de confidencialidade, por mais que você selecione a pessoa, faça testes e muitos outros requisitos de confiabilidade, o que importa são a consistência dos dados e a inviolabilidade do acesso a eles. E encher o kernel de patchs, o firewall de regras e snort + portsentry + ossec ou qualquer outra solução não vai mitigar o risco que levantei. Reveja os seus conceitos sobre segurança de dados. Não existe 100% de segurança. Quanto a uma solução que possa proteger alguns dos seus dados talvez o sepgsql [1] possa te atender. Ele é um módulo carregável que suporta MAC (controle de acesso mandatório) baseado em rótulos. A sua implementação está atrelada ao SELinux. Vale lembrar que há limitações na implementação; sendo assim, ele ainda não controla todas as ações de acesso do PostgreSQL. No wiki há algumas páginas [2] apresentando os conceitos, funcionamento, administração e limitações. [1] http://www.postgresql.org/docs/current/static/sepgsql.html [2] http://wiki.postgresql.org/wiki/SEPostgreSQL -- Euler Taveira de Oliveira - 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] ERRO no arquivamento de logs de transacao. archives do wal
On 27-10-2011 10:42, Dauro Sobrinho wrote: Tente forçar uma sincronização, efetuando o comando CHECKPOINT; dentro do psql. Em seguida verifique se os arquivos foram movidos corretamente. Ugh? CHECKPOINT não está relacionado diretamente a arquivo de log de transação. CHECKPOINT escreve nos *arquivos de dados*. Para mudar para um novo arquivo de log de transação você pode utilizar a função pg_switch_xlog(). PS na semana que vem durante o PGBR, tentarei explicar com detalhes os conceitos por trás de alguns dos termos utilizados no PostgreSQL. Checkpoint e WAL serão alguns deles. -- Euler Taveira de Oliveira - 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] ERRO no arquivamento de logs de transacao. archives do wal
On 27-10-2011 12:13, Flavio Henrique Araque Gurgel wrote: Em outras palavras, veja se já existe o arquivo (%f) no destino (/var/lib/pgsql/archives/) e *se não existir* (test ! -f ...) copie o arquivo a ser arquivado (%p) para lá. E pra quê você faz isso? Não vi necessidade nenhuma. O PostgreSQL só copia o arquivo *uma* vez e o faz até garantir que *foi copiado*. Bastaria o comando cp. O PostgreSQL garante mas eu já vi casos em que o DBA arquivava vários servidores no mesmo local! Parece absurdo mas um 'test ! -f' evitaria sobrescrever um arquivo de log de transação. -- Euler Taveira de Oliveira - 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] ERRO no arquivamento de logs de transacao. archives do wal
On 27-10-2011 22:12, Dauro Sobrinho wrote: Como pode ser visto no link acima (em inglês) o checkpoint está intimamente ligado aos logs de transação. Diferentemente do que o senhor Euler Taveira de Oliveira disse. Você não entendeu. No contexto que você escreveu: Em 27 de outubro de 2011 13:12, Euler Taveira de Oliveira eu...@timbira.com mailto:eu...@timbira.com escreveu: On 27-10-2011 10:42, Dauro Sobrinho wrote: Tente forçar uma sincronização, efetuando o comando CHECKPOINT; dentro do psql. Em seguida verifique se os arquivos foram movidos corretamente. Ugh? CHECKPOINT não está relacionado diretamente a arquivo de log de transação. CHECKPOINT escreve nos *arquivos de dados*. Checkpoint *não* faz com que um novo arquivo de log de transação seja criado. Foi nesse contexto que eu disse que você está equivocado. -- Euler Taveira de Oliveira - 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] servidor standby tentando consumir sempre o mesmo arquivo
On 25-10-2011 10:04, Leonardo Carneiro wrote: Executei a seguinte sequencia de passos: 1) Configurei o archive no master e replication no master #WRITE AHEAD LOG wal_level = hot_standby wal_sync_method = fsync checkpoint_segments = 30 archive_mode = on archive_command = 'ssh postgresql@[host] test ! -f /home/postgresql/remote_logs/%f scp -C %p postgresql@[host]:~/remote_logs/%f' # REPLICATION max_wal_senders = 1 wal_keep_segments = 20 Você não precisa fazer duas conexões ssh no archive_command; utilize somente o último comando. 4) Fiz um tarball do cluster no master Como você copiou? Você não precisa copiar pg_xlog/* pg_log/* e postmaster.pid. 7) Configurei o postgresql.conf no cluster slave com os seguintes parâmetros # WRITE AHEAD LOG wal_level = hot_standby wal_sync_method = fsync checkpoint_segments = 30 # REPLICATION hot_standby = on wal_level = minimal é suficiente; a menos que queira um dia promover o servidor secundário a primário. 9) Movi o conteudo dp pg_xlog do slave para a pasta de recovery, sem sobreescrever eventuais arquivos já existentes bash $ mv -i $PGDATA/pg_xlog/000* /home/postgresql/remote_logs/ Não faça isso. Os arquivos necessários pelo servidor secundário já estão no /home/postgresql/remote_logs. bash $ rm -rf $PGDATA/pg_xlog/* Não se esqueça de remover o postmaster.pid e o conteúdo do diretório pg_log. Como você não está utilizando streaming replication, sugiro que configure o parâmetro archive_timeout para que o servidor secundário não passe longos períodos defasados do servidor principal quando a atividade do banco de dados estiver baixa. -- Euler Taveira de Oliveira - 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] servidor standby tentando consumir sempre o mesmo arquivo
On 25-10-2011 13:06, Leonardo Carneiro wrote: Neste passo segui a recomendação da documentação da documentação. Não é importante verificar a existência de um arquivo do mesmo nome para evitar sobrescrita ou estou perdendo algum ponto aqui? É mas se você tem a garantia que somente um servidor PostgreSQL está arquivando ali, o próprio pg garante que não produzirá arquivos com mesmo nome; consequentemente, você não terá problemas com sobrescrita de arquivos. tar -cvjf bd.tar.bz2 $PGDATA enviei via scp e descompatei do outro lado. Infelizmente eu copiei pg_xlog/* pg_log/* e postmaster.pid. É imperativo que eu não copie eles ou simplesmente não é necessário? Não é necessário. No caso de 'log shipping', somente os arquivos de log *arquivados* são necessários. Ok, vou alterar para minimizar a carga de logs. Na verdade isso não vai minimizar a carga. O parâmetro wal_level só tem efeito se ele *não* for um servidor secundário. -- Euler Taveira de Oliveira - 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] como deixar default o client_encoding
On 25-10-2011 15:03, Moisés Augusto wrote: O client é o SO ? Até mais 2011/10/25 Euler Taveira de Oliveira eu...@timbira.com mailto:eu...@timbira.com On 24-10-2011 23:16, Moisés Augusto wrote: Como podemos setar default o client_encoding dos novos bancos criados ? O próprio nome já diz client_... Que tal fazer isso nas aplicações (vide comando SET)? Você leu o que eu escrevi acima? APLICAÇÃO. -- Euler Taveira de Oliveira - 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] como deixar default o client_encoding
On 24-10-2011 23:16, Moisés Augusto wrote: Como podemos setar default o client_encoding dos novos bancos criados ? O próprio nome já diz client_... Que tal fazer isso nas aplicações (vide comando SET)? -- Euler Taveira de Oliveira - 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] conexão falhada
On 20-10-2011 08:08, Pedro Costa wrote: Já modifiquei o pg_hba.config acrescentando host all all 192.168.1.0 255.255.255.0 trust e o postgres.config confirmei que tinha um asterisco em listen_adresses. O erro que obtenho é: failed to connect to specified server Operation failed. Podem ajudar-me? A entrada do pg_hba.conf está incorreta. O endereço de ser especificado como ip/máscara. Se no seu caso você quer liberar o acesso a toda rede 192.168.1.0 então você deve especificar 192.168.1.0/24. -- Euler Taveira de Oliveira - 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] Dúvidas sobre replicação
On 20-10-2011 19:06, Leandro Guimarães Faria Corce DUTRA wrote: Le 2011-O-20 19h51, Flavio Henrique Araque Gurgel a écrit : Master: SO: Ubuntu Desktop 11.10 x86 PostgreSQL: 9.1.1, compilado direto do fonte Slave SO: Ubuntu Server 11.10 x86_64 PostgreSQL: 9.1.1, compilado direto do fonte Você ainda pode compilar o Slave em 32 bits pra não ter que reinstalar nenhum dos S.Os. Acho que não vale a pena… que me lembre, os ganhos de ter o sistema em 64 bits são maiores que os de compilar. Melhor reinstalar mesmo, e usar pacotes. Então ele vai precisar de _outra_ máquina. Replicação *não* funciona em arquitetura diferentes. -- Euler Taveira de Oliveira - 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] Dúvidas sobre replicação
On 20-10-2011 19:59, Leonardo Carneiro wrote: Esse setup (master x86 e slave x86_64) é apenas um cenário que eu montei com o que tinha em mãos para pode validar os testes. No cenário em produção as máquinas tem a mesma arquitetura. Mesmo compilando o slave em 32 (para não ter o trabalho de formatar uma máquina de desenvolvimento) não vai funcionar, como sugeriu o Leandro? Essa necessidade da mesma arquitetura do cluster é em relação a arquitetura do pg ou a arquitetura da máquina, ou ainda de ambas? =) Leia [1]. [1] http://www.postgresql.org/docs/current/static/warm-standby.html#STANDBY-PLANNING -- Euler Taveira de Oliveira - 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] Dúvidas sobre replicação
On 20-10-2011 21:24, Danilo Silva wrote: Pessoal só uma dúvida, a replicação não roda em arquiteturas diferentes, mas isso é referente somente ao sistema operacional ou vale também pela arquitetura de diretórios? A replicação roda se no master o $PGDATA estiver em /dados/postgresql/ e no slave em /usr/pgsql? Você leu o link enviado? O $PGDATA das duas máquinas pode ser diferente. No entanto, se você estiver utilizando tablespaces, o caminho das mesmas deve ser idêntico em ambas as máquinas. -- Euler Taveira de Oliveira - 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] regras pgadmin
On 18-10-2011 16:23, Edson neto wrote: fiquei com uma dúvida se tivesse um cenario parecido porem não fossem apenas 3 regras abaixo: se o campo cod é 22, a localização só pode ser 22 ou 23 se o campo cod é 23, a localização só pode ser 2 ou 1 se o campo cod é 1e os campos localização e desenho obtêm valor 1 fossem umas 100 regras e houvesse possibilidade de surgirem novas. Ainda sim o mais correto seria uma check constraint ou seria melhor mapear essas regras em uma tabela. E inserir ou atualizar apenas se houvesse uma regra cadastrada? Não. O mais prudente seria um gatilho. Assim, bastaria alterar a função do gatilho toda vez que surgir uma nova regra. -- Euler Taveira de Oliveira - 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] Replicação
On 17-10-2011 10:49, Danilo Silva wrote: Em uma replicação master = slave pelo método streaming replication, faz necessário rodar no slave os comandos vacuumdb e reindex? Detalhe, esses comandos já são executados periodicamente no master. Não. Eles irão causar um erro ao serem executados [1]. Na verdade, as operações de VACUUM e REINDEX executadas no servidor principal reproduzem o resultado no servidor réplica; é como se o VACUUM estivesse executando no servidor réplica exatamente (nas mesmas páginas) como ele é executado no servidor principal. foo=# vacuum verbose bar; ERRO: não pode executar VACUUM durante recuperação [1] http://www.postgresql.org/docs/9.1/static/hot-standby.html#HOT-STANDBY-USERS -- Euler Taveira de Oliveira - 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] NoSQL (era: Configurando Timezones por databases)
On 15-10-2011 00:58, Shander Lyrio wrote: Ele vem agora neste e-mail falar de 7 bilhões/dia, ou seja muito mais que 1000x o valor da entrevista e você quer que eu acredite nisto? Se você acessar os links da entrevista vai ver que o volume comemorado é de 1000 transações por segundo e que foi inflacionado 20x na resposta do Sr. Flávio Gurgel. Você quer que eu respeite alguém, que por falta de argumentos, aumenta o número de transações sobremaneira para forçar um determinado entendimento? [Falando como alguém que realizou inúmeros testes neste ambiente na época e que também trabalhou com o Flavio durante algum tempo neste ambiente...] Você está confundindo ou não está lendo corretamente. O valor menor (1000) são transações bancárias (que pode envolver várias transações do BD). Os 7.10⁹ operações são SELECTs. E como disse o Flavio, são 20.10³ transações no Postgres por segundo. Se ainda assim não estiver convencido que isso é possível, tente agendar uma autorização para conhecer o ambiente. Espero que este seja o último email deste assunto. PS só para lembrar que excessos nesta lista são tratados com moderação ou até exclusão. -- Euler Taveira de Oliveira - 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] NoSQL (era: Configurando Timezones por databases)
On 15-10-2011 22:27, Bruno Silva wrote: E pode tentar conseguir autorização para conhecer o ambiente? Que tal perguntar ao próprio (Flavio) em privado? -- Euler Taveira de Oliveira - 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] [DUVIDA] DBI-Link
On 12-10-2011 23:51, Luís Eduardo Porte wrote: Já efetuei outros testes de conexão do servidor e consigo.. não há bloqueios não. O que diz o log do FreeTDS? Já fizeste um programa em Perl utilizando DBI para verificar se o problema é no DBI-link? -- Euler Taveira de Oliveira - 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] Configurando Timezones por databases
On 13-10-2011 10:47, Pedro Ivo Bispo França wrote: O problema é que se eu altero o timezone da base, TODAS as datas da base, mesmo as anteriores ao horário de verão, vão ser alteradas no output. Como evitar isso? Talvez o a coluna is_dst em pg_timezone_names ajude em algo? Não entendi direito como ela funciona... Isso porque você *não* armazena o timezone no campo data/hora (aka timestamp without time zone). Quando estamos trabalhando com data/hora temos que fazer a seguinte pergunta: a zona horária de armazenamento é a mesma que a de apresentação? Se sim, podemos utilizar o tipo de dado 'timestamp without time zone'; senão, o tipo de dado deve ser 'timestamp with time zone'. A coluna is_dst indica se a zona horária possui horário de verão ou não (aka daylight saving time). Aplicações que funcionam em múltiplas zonas horárias geralmente escolhem uma zona horária padrão (por exemplo, horário de Brasília), utilizam o tipo de dado 'timestamp with time zone' e ao manipular os campos data/hora sempre utilizam AT TIMEZONE 'foo' [1] de acordo com cada caso. [1] http://www.postgresql.org/docs/current/static/functions-datetime.html#FUNCTIONS-DATETIME-ZONECONVERT -- Euler Taveira de Oliveira - 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] Netiqueta (Era: Atualizacao 9.1.0 para 9.1.1)
On 10-10-2011 10:21, Alexsander Rosa wrote: Eu participo de várias listas de emails há décadas (no Brasil e no exterior) e a lista mais netiquette nazi é esta aqui. Faz tempo que não vejo ninguém reclamando nas listas gringas sobre HTML ou posting style [1]. Por exemplo: não sei se em pleno 2011, com banda larga abundante, ainda faz sentido proibir HTML -- ainda mais numa lista onde código-fonte seguidamente aparece nas mensagens. Ugh? Sempre há pelo menos uma menção semanal sobre top-posting nas listas do PostgreSQL. Não vou muito longe [1][2][3]. Quanto ao HTML, quando montei aquelas regras utilizei o termo se possível porque eu sei que para alguns membros o HTML é aceitável (pois os webmails mais populares possuem esta opção). A um tempo atrás quando usava cliente modo texto que não lidava muito bem com HTML, eu simplesmente não participava da discussão. Quanto a código-fonte, o correto seria um anexo e não inline para que a formatação não se perca. [1] http://archives.postgresql.org/pgadmin-hackers/2011-10/msg00030.php [2] http://archives.postgresql.org/pgsql-hackers/2011-08/msg00526.php [3] http://archives.postgresql.org/pgsql-general/2011-07/msg00801.php -- Euler Taveira de Oliveira - 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] Netiqueta (Era: Atualizacao 9.1.0 para 9.1.1)
On 08-10-2011 21:18, Tiago Adami wrote: Esta lista deve passar por um servidor, certo? Será que o moderador/administrador da lista não consegue bloquear o envio de mensagens em HTML no servidor? Ainda teríamos o problema de *bons hábitos* como remover partes de texto desnecessárias e escrever abaixo das outras mensagens, mas já seria um bom começo. É possível bloquear mensagens em HTML mas isso *não* é o caminho porque há muitos clientes que só mandam mensagens em HTML. Não vou discutir o mérito desta decisão mas particularmente acho que usuários que enviam emails para lista deveriam fazer um esforço para seguir as regras da lista. É fato que temos que investir na educação dos usuários (leitura das regras é um bom começo); principalmente a questão do fluxo das conversas (responder no contexto -- abaixo das afirmações ou perguntas). Ainda hoje algumas pessoas pensam que a lista de discussão é o mesmo que um fórum que envia emails. -- Euler Taveira de Oliveira - 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] Desculpem, mais uma vez sobre acentos (LATIN1)
On 07-10-2011 22:26, Bruno Silva wrote: Euler, em tempo no caso de banco latin1/9 em que o initdb tenha sido utf-8 como se deve criar ? Vide [1]. [1] http://listas.postgresql.org.br/pipermail/pgbr-geral/2009-July/016418.html -- Euler Taveira de Oliveira - 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] Migracao de versao - erro no pgrestore
On 05-10-2011 13:51, mauro fonseca wrote: pg_restore: [arquivador personalizado] não pôde reabrir entrada padrão ão foi possível alocar memória Você não mostrou o comando do pg_restore mas ele não irá funcionar se você combinar dados da entrada padrâo com restauração paralela. Quanto ao erro de alocação de memória, provavelmente a sua máquina não possui quantidade suficiente ou o seu usuário não pode utilizá-la (vide ulimit) -- monitore a utilização (por exemplo com dstat ou vmstat) para descobrir o quanto está sendo pedido. Verifique também se o OOM não está terminando o processo do pg_restore (vide dmesg). -- Euler Taveira de Oliveira - 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] Migração da versão 8.2.3 para 9.0.5
On 06-10-2011 21:36, Diego Agudo wrote: Estou migrando um banco de dados do tamanho de 49GB em texto e 9GB em formato custom. Me deparei com o seguinte problema na hora de efetuar o restore: Este processo está demorando muito, deixei mais de 10horas rodando e o restore não volta, /sendo que utilizando a versão 8.2.3 o mesmo processo de dump e restore não passa de 2:30h/. Você tentou utilizar restauração paralela (vide opção -j no pg_restore)? Se você possui índices grandes, experimente aumentar o maintenance_work_mem. Monitore a restauração com a opção -v para ver onde a restauração demora mais tempo. É interessante também acompanhar o estado do SO com ferramentas que observer CPU e IO (como dstat e vmstat). -- Euler Taveira de Oliveira - 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] Limitar acesso
On 07-10-2011 10:49, Bruno Silva wrote: No caso estou sem acesso ao SO. E no 8.0 já tentei colocar o usuário em NOLOGIN e não funciona. Você tem certeza? Sessões já iniciadas não são terminadas. -- Euler Taveira de Oliveira - 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] Migracao de versao - erro no pgrestore
On 07-10-2011 10:57, mauro fonseca wrote: É que as informações principais, ficaram no primeiro post. Mas veja, a servidora tem 128Gb de Ram e 32Nucleos . O restore é porta a porta: pg_dump bd_banco1 --disable-triggers -p 5430 -b -v -Fc | pg_restore --disable-triggers -d bd_banco2 -j 12 1ok 2erro Você não entendeu... Eu estava dizendo quando tentou restaurar a partir do arquivo. Como eu disse no último email, infelizmente restauração paralela não funciona com pipe. :( Tente sem utilizar a opção -j ou divida a sua cópia de segurança em vários pedaços e restaure-os paralelamente. Se o seu tempo de parada não permite, sugiro que utilize streaming replication para transferir os dados de um lado para o outro. -- Euler Taveira de Oliveira - 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] Limitar acesso
On 07-10-2011 11:02, JotaComm wrote: Você alterar o número de conexões do seu banco. ALTER DATABASE nomedobanco SET CONNECTION LIMIT=1; Assim seu banco permitirá apenas uma conexão. É isso que você quer? Não funciona com super-usuários (vide superuser_reserved_connections). -- Euler Taveira de Oliveira - 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
