Re: [pgbr-geral] could not access status of transaction
Não o parâmetro fsync está true. o backup mais recente é de 4 meses atrás, a empresa no qual trabalho desenvolve sistemas públicos aí sabe como é orgão público não se preocupa muito com backup. Date: Thu, 3 Dec 2009 18:01:25 -0200 From: sebastian...@gmail.com To: pgbr-geral@listas.postgresql.org.br Subject: Re: [pgbr-geral] could not access status of transaction 2009/12/3 JacksonWeber jackson...@hotmail.com: SIM HOUVE UMA QUEDA DE ENERGIA E APÓS ISSO COMEÇARAM OS ERROS. Não grite... :P Por um acaso você está com o parametro fsync=off? e o backup? o mais recente é de quando? -- Atenciosamente, Sebastian Selau Webber Colombo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral _ Fique protegido de ameças utilizando o Novo Internet Explorer 8. Baixe já, é grátis! http://brasil.microsoft.com.br/IE8/mergulhe/?utm_source=MSN%3BHotmailutm_medium=Taglineutm_content=Tag1utm_campaign=IE8___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] RE F. Restore não Habilitado.
VisualP Sistemas wrote:
Olá Pessoal,
Estou executando meus backups num arquivo .BAT:
for /f tokens=1,2,3,4 delims=/ %%a in ('DATE /T') do set
Date=%%b-%%c-%%d
pg_dump.exe -i -h localhost -d banco -p 5432 -U user -f C:\%Date%.backup
Funciona 100%.
Ocorre que tentei hoje restaurar no PgAdmin e o mesmo não habilita o OK.
Se eu fizer o mesmo backup pelo PgAdmin ele restaura sem problemas, mas
pelo arquivo .BAT não habilita o restore.
Alguem tem alguma idéia ??
Obrigado.
Paulo.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
-
Tente especificar no comando de backup pg_dump, o formato de arquivo de
saída por que pelo que acompanhei por experiência o pgAdmin não aceita
alguns formatos. Tente acrescentar no arquivo .bat:
pg_dump.exe -i -h localhost -d banco -p 5432 -U user -Fc -f
C:\%Date%.backup
e após o backup ser realizado faça uma restauração pelo pgAdmin.
--
View this message in context:
http://old.nabble.com/REF.-Restore-n%C3%A3o-Habilitado.-tp26631491p26635835.html
Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] RE F. Restore não Habilitado.
Olá JacksonWeber, Ficou Show. Èra exatamente isso. Obrigado pela dica. Att, Paulo. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] QUERY PLAN
Bom dia! Estou fazendo uma consulta e quando o valor de uma coluna é 1 o retorno é rápido (poucos registros). Quando o valor da coluna é 0 o retorno é lento (muitos registros). Será que eu poderia fazer alguma mudança com base no QUERY PLAN? QUERY PLAN HashAggregate (cost=49764.02..49826.68 rows=2785 width=50) (actual time=282.839..282.986 rows=211 loops=1) - Index Scan using S1IP_I01 on stg1_nfe_item_proc item (cost=0.00..49207.14 rows=27844 width=50) (actual time=0.091..55.692 rows=97950 loops=1) Index Cond: (((emit_cMun)::text = '3550308'::text) AND ((ide_tpNF)::text = '0'::text)) * Total runtime: 283.059 ms* (4 registros) QUERY PLAN GroupAggregate (cost=114030.00..119682.56 rows=22839 width=50) (actual time=2116.395..3020.904 rows=13225 loops=1) - Sort (cost=114030.00..114600.97 rows=228386 width=50) (actual time=2116.377..2717.973 rows=184488 loops=1) Sort Key: seqAgrupamento, prod_CFOP, prod_NCM Sort Method: external merge Disk: 12360kB - Bitmap Heap Scan on stg1_nfe_item_proc item (cost=5201.58..78085.37 rows=228386 width=50) (actual time=37.296..146.287 rows=184488 loops=1) Recheck Cond: (((emit_cMun)::text = '3550308'::text) AND ((ide_tpNF)::text = '1'::text)) - Bitmap Index Scan on S1IP_I01 (cost=0.00..5144.49 rows=228386 width=0) (actual time=36.352..36.352 rows=184488 loops=1) Index Cond: (((emit_cMun)::text = '3550308'::text) AND ((ide_tpNF)::text = '1'::text)) * Total runtime: 3026.089 ms* (9 registros) Obrigado! ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] lentidão versao 8.4
Ola turma. Fiz a migração ontem para vesão 8.4 do postgresql e reparei que esta muito lento as querys, vejo o processamento no Linux e todas as consultas utilizando muito processamento, coisa que não ocorria na 8.3. É normal, alguém já passou por isso. Existe alguma forma de melhorar o desempenho nas consultas? Abraços. At. Leandro Müller ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] QUERY PLAN
Olá, 2009/12/4 Thiago Freitas thiago.frei...@gmail.com Bom dia! Estou fazendo uma consulta e quando o valor de uma coluna é 1 o retorno é rápido (poucos registros). Quando o valor da coluna é 0 o retorno é lento (muitos registros). Será que eu poderia fazer alguma mudança com base no QUERY PLAN? QUERY PLAN HashAggregate (cost=49764.02..49826.68 rows=2785 width=50) (actual time=282.839..282.986 rows=211 loops=1) - Index Scan using S1IP_I01 on stg1_nfe_item_proc item (cost=0.00..49207.14 rows=27844 width=50) (actual time=0.091..55.692 rows=97950 loops=1) Index Cond: (((emit_cMun)::text = '3550308'::text) AND ((ide_tpNF)::text = '0'::text)) * Total runtime: 283.059 ms* (4 registros) QUERY PLAN GroupAggregate (cost=114030.00..119682.56 rows=22839 width=50) (actual time=2116.395..3020.904 rows=13225 loops=1) - Sort (cost=114030.00..114600.97 rows=228386 width=50) (actual time=2116.377..2717.973 rows=184488 loops=1) Sort Key: seqAgrupamento, prod_CFOP, prod_NCM Sort Method: external merge Disk: 12360kB - Bitmap Heap Scan on stg1_nfe_item_proc item (cost=5201.58..78085.37 rows=228386 width=50) (actual time=37.296..146.287 rows=184488 loops=1) Recheck Cond: (((emit_cMun)::text = '3550308'::text) AND ((ide_tpNF)::text = '1'::text)) - Bitmap Index Scan on S1IP_I01 (cost=0.00..5144.49 rows=228386 width=0) (actual time=36.352..36.352 rows=184488 loops=1) Index Cond: (((emit_cMun)::text = '3550308'::text) AND ((ide_tpNF)::text = '1'::text)) * Total runtime: 3026.089 ms* (9 registros) Obrigado! Esta sua coluna está indexada? Índice parcial? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral []s -- JotaComm http://jotacomm.wordpress.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] lentidão versao 8.4
Olá, 2009/12/4 Leandro Müller leandroli...@muriki.com.br Ola turma. Fiz a migração ontem para vesão 8.4 do postgresql e reparei que esta muito lento as querys, vejo o processamento no Linux e todas as consultas utilizando muito processamento, coisa que não ocorria na 8.3. É normal, alguém já passou por isso. Existe alguma forma de melhorar o desempenho nas consultas? Abraços. Você executou uma analyze após o fim do processo de migração? Alterou alguma configuração no postgresql.conf? Quais consultas que estão lentas? Elas não estava lentas antes? At. Leandro Müller ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral []s -- JotaComm http://jotacomm.wordpress.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] lentidão versao 8.4
Bom dia, Estranha essa queda em desempenho. Para ajudar-te precisamos de um pouco mais de dados: todas as queries estão mais lentas ou apenas alguma especificamente? Além do tempo, também estás com problema de consumo de processamento, certo? Tem maior consumo de memória utilizada também ou não? O config do postgreSQL foi alterado ou está o padrão? Se puderes, dê mais detalhes de teu banco de dados, o que for possível, para entendermos o que pode estar ocorrendo. Em geral, o desempenho de consultas com o postgreSQL 8.4 é superior ao com o 8.3, mas sempre pode haver uma exceção. Mesmo assim sempre há como voltar a um desempenho otimizado. Abraços, 2009/12/4 Leandro Müller leandroli...@muriki.com.br Ola turma. Fiz a migração ontem para vesão 8.4 do postgresql e reparei que esta muito lento as querys, vejo o processamento no Linux e todas as consultas utilizando muito processamento, coisa que não ocorria na 8.3. É normal, alguém já passou por isso. Existe alguma forma de melhorar o desempenho nas consultas? Abraços. At. Leandro Müller ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- André de Camargo Fernandes ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] QUERY PLAN
O problema são os valores ZERO ou UM pra coluna *ide_tpNF* Índices: S1IP_I01 btree (emit_cMun, *ide_tpNF*) CLUSTER On Fri, Dec 4, 2009 at 9:28 AM, JotaComm jota.c...@gmail.com wrote: Olá, 2009/12/4 Thiago Freitas thiago.frei...@gmail.com Bom dia! Estou fazendo uma consulta e quando o valor de uma coluna é 1 o retorno é rápido (poucos registros). Quando o valor da coluna é 0 o retorno é lento (muitos registros). Será que eu poderia fazer alguma mudança com base no QUERY PLAN? QUERY PLAN HashAggregate (cost=49764.02..49826.68 rows=2785 width=50) (actual time=282.839..282.986 rows=211 loops=1) - Index Scan using S1IP_I01 on stg1_nfe_item_proc item (cost=0.00..49207.14 rows=27844 width=50) (actual time=0.091..55.692 rows=97950 loops=1) Index Cond: (((emit_cMun)::text = '3550308'::text) AND ((ide_tpNF)::text = '0'::text)) * Total runtime: 283.059 ms* (4 registros) QUERY PLAN GroupAggregate (cost=114030.00..119682.56 rows=22839 width=50) (actual time=2116.395..3020.904 rows=13225 loops=1) - Sort (cost=114030.00..114600.97 rows=228386 width=50) (actual time=2116.377..2717.973 rows=184488 loops=1) Sort Key: seqAgrupamento, prod_CFOP, prod_NCM Sort Method: external merge Disk: 12360kB - Bitmap Heap Scan on stg1_nfe_item_proc item (cost=5201.58..78085.37 rows=228386 width=50) (actual time=37.296..146.287 rows=184488 loops=1) Recheck Cond: (((emit_cMun)::text = '3550308'::text) AND ((ide_tpNF)::text = '1'::text)) - Bitmap Index Scan on S1IP_I01 (cost=0.00..5144.49 rows=228386 width=0) (actual time=36.352..36.352 rows=184488 loops=1) Index Cond: (((emit_cMun)::text = '3550308'::text) AND ((ide_tpNF)::text = '1'::text)) * Total runtime: 3026.089 ms* (9 registros) Obrigado! Esta sua coluna está indexada? Índice parcial? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral []s -- JotaComm http://jotacomm.wordpress.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] QUERY PLAN
2009/12/4 JotaComm jota.c...@gmail.com: Olá, 2009/12/4 Thiago Freitas thiago.frei...@gmail.com Bom dia! Estou fazendo uma consulta e quando o valor de uma coluna é 1 o retorno é rápido (poucos registros). Quando o valor da coluna é 0 o retorno é lento (muitos registros). Será que eu poderia fazer alguma mudança com base no QUERY PLAN? QUERY PLAN HashAggregate (cost=49764.02..49826.68 rows=2785 width=50) (actual time=282.839..282.986 rows=211 loops=1) - Index Scan using S1IP_I01 on stg1_nfe_item_proc item (cost=0.00..49207.14 rows=27844 width=50) (actual time=0.091..55.692 rows=97950 loops=1) Index Cond: (((emit_cMun)::text = '3550308'::text) AND ((ide_tpNF)::text = '0'::text)) Total runtime: 283.059 ms (4 registros) QUERY PLAN GroupAggregate (cost=114030.00..119682.56 rows=22839 width=50) (actual time=2116.395..3020.904 rows=13225 loops=1) - Sort (cost=114030.00..114600.97 rows=228386 width=50) (actual time=2116.377..2717.973 rows=184488 loops=1) Sort Key: seqAgrupamento, prod_CFOP, prod_NCM Sort Method: external merge Disk: 12360kB - Bitmap Heap Scan on stg1_nfe_item_proc item (cost=5201.58..78085.37 rows=228386 width=50) (actual time=37.296..146.287 rows=184488 loops=1) Recheck Cond: (((emit_cMun)::text = '3550308'::text) AND ((ide_tpNF)::text = '1'::text)) - Bitmap Index Scan on S1IP_I01 (cost=0.00..5144.49 rows=228386 width=0) (actual time=36.352..36.352 rows=184488 loops=1) Index Cond: (((emit_cMun)::text = '3550308'::text) AND ((ide_tpNF)::text = '1'::text)) Total runtime: 3026.089 ms (9 registros) Obrigado! Esta sua coluna está indexada? Índice parcial? É a mesma consulta em ambos os casos com a diferença do parâmetro ide_tpNF? Você percebeu que a segunda está swapando (Sort Method: external merge Disk: 12360kB)? Veja que as estimativas estão um pouco estranhas também, rodou ANALYZE? []s Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] QUERY PLAN
Thiago Freitas escreveu: QUERY PLAN GroupAggregate (cost=114030.00..119682.56 rows=22839 width=50) (actual time=2116.395..3020.904 rows=13225 loops=1) - Sort (cost=114030.00..114600.97 rows=228386 width=50) (actual time=2116.377..2717.973 rows=184488 loops=1) Sort Key: seqAgrupamento, prod_CFOP, prod_NCM Sort Method: external merge Disk: 12360kB Só um pequeno palpite aqui nesse ponto: aumente o seu work_mem para 16MB e tente novamente. []´s, André Volpato ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] QUERY PLAN
Exato, a mesma consulta com esta única diferença. Realmente, eu percebi esta mensagem mas não sei o que devo fazer... 2009/12/4 Dickson S. Guedes lis...@guedesoft.net 2009/12/4 JotaComm jota.c...@gmail.com: Olá, 2009/12/4 Thiago Freitas thiago.frei...@gmail.com Bom dia! Estou fazendo uma consulta e quando o valor de uma coluna é 1 o retorno é rápido (poucos registros). Quando o valor da coluna é 0 o retorno é lento (muitos registros). Será que eu poderia fazer alguma mudança com base no QUERY PLAN? QUERY PLAN HashAggregate (cost=49764.02..49826.68 rows=2785 width=50) (actual time=282.839..282.986 rows=211 loops=1) - Index Scan using S1IP_I01 on stg1_nfe_item_proc item (cost=0.00..49207.14 rows=27844 width=50) (actual time=0.091..55.692 rows=97950 loops=1) Index Cond: (((emit_cMun)::text = '3550308'::text) AND ((ide_tpNF)::text = '0'::text)) Total runtime: 283.059 ms (4 registros) QUERY PLAN GroupAggregate (cost=114030.00..119682.56 rows=22839 width=50) (actual time=2116.395..3020.904 rows=13225 loops=1) - Sort (cost=114030.00..114600.97 rows=228386 width=50) (actual time=2116.377..2717.973 rows=184488 loops=1) Sort Key: seqAgrupamento, prod_CFOP, prod_NCM Sort Method: external merge Disk: 12360kB - Bitmap Heap Scan on stg1_nfe_item_proc item (cost=5201.58..78085.37 rows=228386 width=50) (actual time=37.296..146.287 rows=184488 loops=1) Recheck Cond: (((emit_cMun)::text = '3550308'::text) AND ((ide_tpNF)::text = '1'::text)) - Bitmap Index Scan on S1IP_I01 (cost=0.00..5144.49 rows=228386 width=0) (actual time=36.352..36.352 rows=184488 loops=1) Index Cond: (((emit_cMun)::text = '3550308'::text) AND ((ide_tpNF)::text = '1'::text)) Total runtime: 3026.089 ms (9 registros) Obrigado! Esta sua coluna está indexada? Índice parcial? É a mesma consulta em ambos os casos com a diferença do parâmetro ide_tpNF? Você percebeu que a segunda está swapando (Sort Method: external merge Disk: 12360kB)? Veja que as estimativas estão um pouco estranhas também, rodou ANALYZE? []s Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Erro Drop table
DROP TABLE public.car; ERROR: con_pkey is an index A tabela car tem uma fk para tabela con. Ja tentei deletar a fk primeiro tb deu o mesmo erro. -- View this message in context: http://old.nabble.com/Erro-Drop-table-tp26635867p26635867.html Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Erro Drop table
Olá, 2009/12/4 mateusgra mateus...@bol.com.br DROP TABLE public.car; ERROR: con_pkey is an index A tabela car tem uma fk para tabela con. Ja tentei deletar a fk primeiro tb deu o mesmo erro. Você deve ter algumas restrições de integridade, você não vai conseguir dropar uma tabela que tenham tabelas que referenciam esta tabela, primeiro terá que tratar ou deletar as tabelas dependentes e depois a tabela em questão. -- View this message in context: http://old.nabble.com/Erro-Drop-table-tp26635867p26635867.html Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral []s -- JotaComm http://jotacomm.wordpress.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] QUERY PLAN
2009/12/4 JotaComm jota.c...@gmail.com: Olá, 2009/12/4 Thiago Freitas thiago.frei...@gmail.com Exato, a mesma consulta com esta única diferença. Realmente, eu percebi esta mensagem mas não sei o que devo fazer... O André comentou de aumentar o work_mem. O valor padrão é 1 MB, sempre que você tem operações de ORDER BY e GROUP BY. Você pode fazer o seguinte teste: SET work_mem TO 10MB; Sua consulta. E ver o resultado, ao fim você pode fazer SET work_mem TO DEFAULT; Ou ao deixar a sessão automaticamente o valor é retorno ao original visto que sua modificação foi na seção. O Guedes comentou do ANALYZE. Você já executou esta operação? Além do que o Jota falou, você tem como nos informar qual o número de registros a tabela em questão possui, quantos resultados retornam para o '0' e quantos para o '1'? Dependendo destes valores pode ser normal ambos os planos, Mais uma coisa, tente executar a segunda consulta, porém desabilitando o bitmap scan e re-execute o EXPLAIN para ver se ele melhora em relação à outra. No PSQL: SET enable_bitmapscan TO off; EXPLAIN ... Poste estes resultados na aqui lista para analisarmos. []s Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] QUERY PLAN
Eu alterei o wok_mem para 16MB e a consulta que demorava 3 segundos caiu para menos de meio segundo. Pessoal, obrigado pela ajuda! Att, Thiago Freitas 2009/12/4 Dickson S. Guedes lis...@guedesoft.net 2009/12/4 JotaComm jota.c...@gmail.com: Olá, 2009/12/4 Thiago Freitas thiago.frei...@gmail.com Exato, a mesma consulta com esta única diferença. Realmente, eu percebi esta mensagem mas não sei o que devo fazer... O André comentou de aumentar o work_mem. O valor padrão é 1 MB, sempre que você tem operações de ORDER BY e GROUP BY. Você pode fazer o seguinte teste: SET work_mem TO 10MB; Sua consulta. E ver o resultado, ao fim você pode fazer SET work_mem TO DEFAULT; Ou ao deixar a sessão automaticamente o valor é retorno ao original visto que sua modificação foi na seção. O Guedes comentou do ANALYZE. Você já executou esta operação? Além do que o Jota falou, você tem como nos informar qual o número de registros a tabela em questão possui, quantos resultados retornam para o '0' e quantos para o '1'? Dependendo destes valores pode ser normal ambos os planos, Mais uma coisa, tente executar a segunda consulta, porém desabilitando o bitmap scan e re-execute o EXPLAIN para ver se ele melhora em relação à outra. No PSQL: SET enable_bitmapscan TO off; EXPLAIN ... Poste estes resultados na aqui lista para analisarmos. []s Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] RES: lentidão versao 8.4
Instalei o postgresql 8.4 do zero, restaurei minha base de dados, não fiz nenhuma modificação no postgresql.conf. Todas as consultas são lentas. Retornei para o 8.3 e esta tudo normalizado. Abraços. At. Leandro Müller De: pgbr-geral-boun...@listas.postgresql.org.br [mailto:pgbr-geral-boun...@listas.postgresql.org.br] Em nome de JotaComm Enviada em: sexta-feira, 4 de dezembro de 2009 09:30 Para: Comunidade PostgreSQL Brasileira Assunto: Re: [pgbr-geral] lentidão versao 8.4 Olá, 2009/12/4 Leandro Müller leandroli...@muriki.com.br Ola turma. Fiz a migração ontem para vesão 8.4 do postgresql e reparei que esta muito lento as querys, vejo o processamento no Linux e todas as consultas utilizando muito processamento, coisa que não ocorria na 8.3. É normal, alguém já passou por isso. Existe alguma forma de melhorar o desempenho nas consultas? Abraços. Você executou uma analyze após o fim do processo de migração? Alterou alguma configuração no postgresql.conf? Quais consultas que estão lentas? Elas não estava lentas antes? At. Leandro Müller ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral []s -- JotaComm http://jotacomm.wordpress.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Erro Drop table
On Fri, Dec 4, 2009 at 10:05 AM, Rodrigo Lang rodrigoferreiral...@gmail.com wrote: Mateus, acho que o comando DROP TABLE public.car CASCADE; resolva seu problema... Tome cuidado! isso pode fazer um super estrago no seu banco de dados. Com o cascade, o drop vai apagar todas as tabelas que dependam nessa. Use com moderação... -- Atenciosamente, Sebastian Selau Webber Colombo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] could not access status of transaction
2009/12/4 Jackson Schmitz Weber jackson...@hotmail.com: Não o parâmetro fsync está true. o backup mais recente é de 4 meses atrás, a empresa no qual trabalho desenvolve sistemas públicos aí sabe como é orgão público não se preocupa muito com backup. Você consegue fazer um dump do banco que roda nessa instância? Acho que depois que explode o pg_clog, não há muito que possa ser feito. -- Atenciosamente, Sebastian Selau Webber Colombo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Erro: SHGetFolderPath
Olá Pessoal Estou com um problema e gostaria de uma resposta, tenho um cliente que usa Windows98 e não aceita mudar ou comprar novos equipamentos. Eu preciso acessar a base de dados em Postgres em outro computador, estou recebendo o erro: O arquivo LIBPQ.DLL está vincunlado ao SHELL32.DLL de exportação que não foi encontrado: SHGetFolderPathA Alguém pode me dar uma ajuda? Obrigado! Adilson Nunes ___ 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 Drop table
Sebastian SWC escreveu: On Fri, Dec 4, 2009 at 10:05 AM, Rodrigo Lang rodrigoferreiralang-re5jqeeqqe8avxtiumw...@public.gmane.org wrote: Mateus, acho que o comando DROP TABLE public.car CASCADE; resolva seu problema... Tome cuidado! isso pode fazer um super estrago no seu banco de dados. Com o cascade, o drop vai apagar todas as tabelas que dependam nessa. Use com moderação... Com drop cascade aconteceu o mesmo erro. Nenhuma tabela depende de car. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] ERROR: out of memory Failed on request of size 88.
Estou executando uma rotina de reprocessamento na minha máquina, que roda Windows Vista Home Premium 32-bit e PostgreSQL 8.4.1. Com o mesmo database em um servidor de produção rodando Ubuntu Linux 8.04 32-bit e PostgreSQL 8.2.12, o erro não acontece. A rotina é na aplicação, executando mais de 50.000 comandos SQL dentro da transação (distribuídos entre INSERTS, UPDATES, DELETES e SELECTS). Chega um momento que o PostgreSQL simplesmente abre as pernas. A máquina fica impossível de ser utilizada, e logo em seguida a mensagem de erro é retornada pela aplicação: [SQL Error] Connectivity error: [SQL State] 53200 [Mensagem do driver ODBC] ERROR: out of memory Failed on request of size 88.; Error while executing the query [Código SQL] SELECT * FROM PCCMESD0 WHERE EMPFIL='0012' AND ITEM='414719' AND DTMOVI='2009-11-27' O que poderia ser? Seria este algum bug da 8.4.1 ou um bom motivo para usar Linux? ;) Por questões de tempo e complexidade da rotina, não há como implementá-la dentro de uma função em Pl/PgSQL. Eu sei que esta é a melhor alternativa, mas não dispomos de tempo para fazê-lo, visto que todas as regras de negócio utilizas estão no aplicativo. -- TIAGO J. ADAMI http://www.adamiworks.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Problema Query PostgreSQL 8.2.13 !!!
Prezada Comunidade PostgreSQL, Trabalhamos com soluções em Data Center e temos um cenário de um cliente que este nos preocupando, logo estamos reportando a comunidade, a fim de buscar uma luz no final do túnel, sendo assim segue nosso cenário: * Servidor FreeBSD 8.0 64bits * Pacostes instalados: postgresql-client-8.2.13 PostgreSQL database (client) postgresql-contrib-8.2.13_2 The contrib utilities from the PostgreSQL distribution postgresql-server-8.2.13 The most advanced open-source database available anywhere * Problema: Ao executarmo a mesma query no servidor do cliente esta demora menos de 02:30 minutos já no cenário apresentado esta demorando mais de 03:30, sendo assim segue a forma que estamos executando a query: |_r...@cliente: 10:29:36 ~_| date; time psql banco tabela -f consulta.sql 1 /dev/null 2 /dev/null Ao analisarmos o consumo dos recursos do servidor notamos o seguinte problema: |_r...@cliente: 10:29:51 ~_| top last pid: 37984; load averages: 0.63, 0.18, 0.06 up 0+05:38:26 10:30:59 46 processes: 2 running, 44 sleeping CPU: 49.2% user, 0.0% nice, 0.8% system, 0.4% interrupt, 49.6% idle Mem: 105M Active, 18M Inact, 92M Wired, 228K Cache, 81M Buf, 1783M Free Swap: 8192M Total, 8192M Free PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 37982 pgsql 1 1180 115M 49708K CPU11 1:01 100.00% postgres 861 root1 440 6676K 3768K select 0 0:10 0.00% sshd 823 pgsql 1 440 83712K 9784K select 0 0:04 0.00% postgres 596 root1 440 3344K 1244K select 0 0:01 0.00% syslogd 832 www 1 440 6028K 3476K kqread 0 0:01 0.00% lighttpd 868 root1 440 6072K 3548K select 0 0:00 0.00% sendmail 824 pgsql 1 440 10400K 4528K select 0 0:00 0.00% postgres 887 www 1 450 29704K 18156K accept 1 0:00 0.00% php-cgi 875 www 1 450 29704K 18160K accept 1 0:00 0.00% php-cgi 846 www 1 510 27656K 14448K wait0 0:00 0.00% php-cgi 858 www 1 510 27656K 14676K wait0 0:00 0.00% php-cgi 859 www 1 520 27656K 14768K wait0 0:00 0.00% php-cgi 860 www 1 520 27656K 14852K wait1 0:00 0.00% php-cgi 821 pgsql 1 440 83712K 9744K select 0 0:00 0.00% postgres 894 root1 440 3372K 1372K nanslp 0 0:00 0.00% cron 28908 pgsql 1 460 84736K 12956K sbwait 1 0:00 0.00% postgres 37979 root1 440 3680K 1928K CPU00 0:00 0.00% top 28909 pgsql 1 470 84736K 12972K sbwait 1 0:00 0.00% postgres 37973 root1 440 9400K 4416K select 0 0:00 0.00% sshd 37976 root1 440 4560K 2404K wait0 0:00 0.00% bash 37981 root1 450 6972K 3572K select 1 0:00 0.00% psql 37978 root1 440 4560K 2404K wait0 0:00 0.00% bash 872 smmsp 1 440 6072K 3464K pause 1 0:00 0.00% sendmail 950 root1 760 3344K 1180K ttyin 0 0:00 0.00% getty 948 root1 760 3344K 1180K ttyin 1 0:00 0.00% getty 954 root1 760 3344K 1180K ttyin 0 0:00 0.00% getty 952 root1 760 3344K 1180K ttyin 1 0:00 0.00% getty 953 root1 760 3344K 1180K ttyin 1 0:00 0.00% getty 951 root1 760 3344K 1180K ttyin 0 0:00 0.00% getty 949 root1 760 3344K 1180K ttyin 1 0:00 0.00% getty 955 root1 760 3344K 1180K ttyin 0 0:00 0.00% getty 478 root1 440 1888K 540K select 1 0:00 0.00% devd 889 www 1 520 27656K 14800K accept 1 0:00 0.00% php-cgi 888 www 1 520 27656K 14800K accept 1 0:00 0.00% php-cgi 877 www 1 520 27656K 14884K accept 1 0:00 0.00% php-cgi 874 www 1 510 27656K 14480K accept 0 0:00 0.00% php-cgi 881 www 1 510 27656K 14708K accept 1 0:00 0.00% php-cgi 879 www 1 520 27656K 14884K accept 1 0:00 0.00% php-cgi 890 www 1 530 27656K 14800K accept 1 0:00 0.00% php-cgi 883 www 1 510 27656K 14708K accept 1 0:00 0.00% php-cgi 876 www 1 510 27656K 14480K accept 0 0:00 0.00% php-cgi 878 www 1 510 27656K 14480K accept 0 0:00 0.00% php-cgi 873 www 1 510 27656K 14480K accept 1 0:00 0.00% php-cgi 880 www 1 520 27656K 14884K accept 0 0:00 0.00% php-cgi 882 www 1 510 27656K 14708K accept 1 0:00 0.00% php-cgi 885 www 1 510 27656K 14708K accept 1 0:00 0.00% php-cgi Como podem perceber acima o servidor esta com memória, hard drive e cpu com disponibilidade considerável, mas detectamos que somente um processo: postgresql 37982 esta com 100% de uso, mesmo tendo recursos no equipamento disponíveis, parecendo que o PostgreSQL
Re: [pgbr-geral] ERROR: out of memory Failed on request of size 88.
Olá 2009/12/4 Tiago Adami adam...@gmail.com Estou executando uma rotina de reprocessamento na minha máquina, que roda Windows Vista Home Premium 32-bit e PostgreSQL 8.4.1. Com o mesmo database em um servidor de produção rodando Ubuntu Linux 8.04 32-bit e PostgreSQL 8.2.12, o erro não acontece. A rotina é na aplicação, executando mais de 50.000 comandos SQL dentro da transação (distribuídos entre INSERTS, UPDATES, DELETES e SELECTS). Chega um momento que o PostgreSQL simplesmente abre as pernas. A máquina fica impossível de ser utilizada, e logo em seguida a mensagem de erro é retornada pela aplicação: [SQL Error] Connectivity error: [SQL State] 53200 [Mensagem do driver ODBC] ERROR: out of memory Failed on request of size 88.; Error while executing the query [Código SQL] SELECT * FROM PCCMESD0 WHERE EMPFIL='0012' AND ITEM='414719' AND DTMOVI='2009-11-27' O que poderia ser? Seria este algum bug da 8.4.1 ou um bom motivo para usar Linux? ;) Nunca é tarde... No entanto não deveria ocorrer isso. Você poderia enviar os logs do banco de dados quando esse problema ocorre ? -- Marcelo Costa www.marcelocosta.net - “You can't always get what want”, Doctor House in apology to Mike Jagger ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] QUERY PLAN
2009/12/4 Thiago Freitas thiago.frei...@gmail.com: Eu alterei o wok_mem para 16MB e a consulta que demorava 3 segundos caiu para menos de meio segundo. Pessoal, obrigado pela ajuda! E quanto ao plano? Consegue postar aqui? Rodou o ANALYZE nas tabelas envolvidas? []s Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] QUERY PLAN
* work_mem = 1MB* QUERY PLAN GroupAggregate (cost=114030.00..119682.56 rows=22839 width=50) (actual time=2116.395..3020.904 rows=13225 loops=1) - Sort (cost=114030.00..114600.97 rows=228386 width=50) (actual time=2116.377..2717.973 rows=184488 loops=1) Sort Key: seqAgrupamento, prod_CFOP, prod_NCM *Sort Method: external merge Disk: 12360kB* - Bitmap Heap Scan on stg1_nfe_item_proc item (cost=5201.58..78085.37 rows=228386 width=50) (actual time=37.296..146.287 rows=184488 loops=1) Recheck Cond: (((emit_cMun)::text = '3550308'::text) AND ((ide_tpNF)::text = '1'::text)) - Bitmap Index Scan on S1IP_I01 (cost=0.00..5144.49 rows=228386 width=0) (actual time=36.352..36.352 rows=184488 loops=1) Index Cond: (((emit_cMun)::text = '3550308'::text) AND ((ide_tpNF)::text = '1'::text)) *Total runtime: 3026.089 ms* * * * *work_mem = 16MB* QUERY PLAN HashAggregate (cost=82653.09..83166.97 rows=22839 width=50) (actual time=486.177..496.042 rows=13225 loops=1) - Bitmap Heap Scan on stg1_nfe_item_proc item (cost=5201.58..78085.37 rows=228386 width=50) (actual time=36.831..89.838 rows=184488 loops=1) Recheck Cond: (((emit_cMun)::text = '3550308'::text) AND ((ide_tpNF)::text = '1'::text)) - Bitmap Index Scan on S1IP_I01 (cost=0.00..5144.49 rows=228386 width=0) (actual time=35.868..35.868 rows=184488 loops=1) Index Cond: (((emit_cMun)::text = '3550308'::text) AND ((ide_tpNF)::text = '1'::text)) Total runtime: 497.319 ms 2009/12/4 Dickson S. Guedes lis...@guedesoft.net 2009/12/4 Thiago Freitas thiago.frei...@gmail.com: Eu alterei o wok_mem para 16MB e a consulta que demorava 3 segundos caiu para menos de meio segundo. Pessoal, obrigado pela ajuda! E quanto ao plano? Consegue postar aqui? Rodou o ANALYZE nas tabelas envolvidas? []s Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] ERROR: out of memory Failed on request of size 88.
2009/12/4 Marcelo Costa marcelojsco...@gmail.com: Olá 2009/12/4 Tiago Adami adam...@gmail.com Estou executando uma rotina de reprocessamento na minha máquina, que roda Windows Vista Home Premium 32-bit e PostgreSQL 8.4.1. Com o mesmo database em um servidor de produção rodando Ubuntu Linux 8.04 32-bit e PostgreSQL 8.2.12, o erro não acontece. A rotina é na aplicação, executando mais de 50.000 comandos SQL dentro da transação (distribuídos entre INSERTS, UPDATES, DELETES e SELECTS). Chega um momento que o PostgreSQL simplesmente abre as pernas. A máquina fica impossível de ser utilizada, e logo em seguida a mensagem de erro é retornada pela aplicação: [SQL Error] Connectivity error: [SQL State] 53200 [Mensagem do driver ODBC] ERROR: out of memory Failed on request of size 88.; Error while executing the query [Código SQL] SELECT * FROM PCCMESD0 WHERE EMPFIL='0012' AND ITEM='414719' AND DTMOVI='2009-11-27' O que poderia ser? Seria este algum bug da 8.4.1 ou um bom motivo para usar Linux? ;) Nunca é tarde... No entanto não deveria ocorrer isso. Você poderia enviar os logs do banco de dados quando esse problema ocorre ? Qual o nível de log seria suficiente para este caso? (DEBUG1, DEBUG2, etc). No log consta apenas registros do tipo: CurTransactionContext: 8192 total in 1 blocks; 8176 free (1 chunks); 16 used -- TIAGO J. ADAMI http://www.adamiworks.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] mamooth / objectRMMS
Alguém aqui já usou mamooth replicator https://projects.commandprompt.com/public/replicator/wiki/QuickStart objectRMMS http://www.object.com.br/content/view/26/40/ e tem alguma experiência para compartilhar? Dúvida sobre replicação master-slave: - esta pode ser bidirecional, ou seja, ocorrer alguma atualzação/inserção no slave e ser replicada no master, ou obrigatoriamente não? Pergunto isso porque só achei duas soluções assincronas para windows (mamooth / objectRMMS) sendo que o mamooth é master-multislave e o objectRMMS é multimaster. Obrigado - Rudinei Dias ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Query PostgreSQL 8.2.13 !!!
Olá 2009/12/4 Marcelo Barbosa marcelo.barb...@sizeof.com.br Prezada Comunidade PostgreSQL, Trabalhamos com soluções em Data Center e temos um cenário de um cliente que este nos preocupando, logo estamos reportando a comunidade, a fim de buscar uma luz no final do túnel, sendo assim segue nosso cenário: * Servidor FreeBSD 8.0 64bits * Pacostes instalados: postgresql-client-8.2.13 PostgreSQL database (client) postgresql-contrib-8.2.13_2 The contrib utilities from the PostgreSQL distribution postgresql-server-8.2.13 The most advanced open-source database available anywhere * Problema: Ao executarmo a mesma query no servidor do cliente esta demora menos de 02:30 minutos já no cenário apresentado esta demorando mais de 03:30, sendo assim segue a forma que estamos executando a query: |_r...@cliente: 10:29:36 ~_| date; time psql banco tabela -f consulta.sql 1 /dev/null 2 /dev/null Ao analisarmos o consumo dos recursos do servidor notamos o seguinte problema: |_r...@cliente: 10:29:51 ~_| top last pid: 37984; load averages: 0.63, 0.18, 0.06 up 0+05:38:26 10:30:59 46 processes: 2 running, 44 sleeping CPU: 49.2% user, 0.0% nice, 0.8% system, 0.4% interrupt, 49.6% idle Mem: 105M Active, 18M Inact, 92M Wired, 228K Cache, 81M Buf, 1783M Free Swap: 8192M Total, 8192M Free PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 37982 pgsql 1 1180 115M 49708K CPU11 1:01 100.00% postgres 861 root1 440 6676K 3768K select 0 0:10 0.00% sshd 823 pgsql 1 440 83712K 9784K select 0 0:04 0.00% postgres 596 root1 440 3344K 1244K select 0 0:01 0.00% syslogd 832 www 1 440 6028K 3476K kqread 0 0:01 0.00% lighttpd 868 root1 440 6072K 3548K select 0 0:00 0.00% sendmail 824 pgsql 1 440 10400K 4528K select 0 0:00 0.00% postgres 887 www 1 450 29704K 18156K accept 1 0:00 0.00% php-cgi 875 www 1 450 29704K 18160K accept 1 0:00 0.00% php-cgi 846 www 1 510 27656K 14448K wait0 0:00 0.00% php-cgi 858 www 1 510 27656K 14676K wait0 0:00 0.00% php-cgi 859 www 1 520 27656K 14768K wait0 0:00 0.00% php-cgi 860 www 1 520 27656K 14852K wait1 0:00 0.00% php-cgi 821 pgsql 1 440 83712K 9744K select 0 0:00 0.00% postgres 894 root1 440 3372K 1372K nanslp 0 0:00 0.00% cron 28908 pgsql 1 460 84736K 12956K sbwait 1 0:00 0.00% postgres 37979 root1 440 3680K 1928K CPU00 0:00 0.00% top 28909 pgsql 1 470 84736K 12972K sbwait 1 0:00 0.00% postgres 37973 root1 440 9400K 4416K select 0 0:00 0.00% sshd 37976 root1 440 4560K 2404K wait0 0:00 0.00% bash 37981 root1 450 6972K 3572K select 1 0:00 0.00% psql 37978 root1 440 4560K 2404K wait0 0:00 0.00% bash 872 smmsp 1 440 6072K 3464K pause 1 0:00 0.00% sendmail 950 root1 760 3344K 1180K ttyin 0 0:00 0.00% getty 948 root1 760 3344K 1180K ttyin 1 0:00 0.00% getty 954 root1 760 3344K 1180K ttyin 0 0:00 0.00% getty 952 root1 760 3344K 1180K ttyin 1 0:00 0.00% getty 953 root1 760 3344K 1180K ttyin 1 0:00 0.00% getty 951 root1 760 3344K 1180K ttyin 0 0:00 0.00% getty 949 root1 760 3344K 1180K ttyin 1 0:00 0.00% getty 955 root1 760 3344K 1180K ttyin 0 0:00 0.00% getty 478 root1 440 1888K 540K select 1 0:00 0.00% devd 889 www 1 520 27656K 14800K accept 1 0:00 0.00% php-cgi 888 www 1 520 27656K 14800K accept 1 0:00 0.00% php-cgi 877 www 1 520 27656K 14884K accept 1 0:00 0.00% php-cgi 874 www 1 510 27656K 14480K accept 0 0:00 0.00% php-cgi 881 www 1 510 27656K 14708K accept 1 0:00 0.00% php-cgi 879 www 1 520 27656K 14884K accept 1 0:00 0.00% php-cgi 890 www 1 530 27656K 14800K accept 1 0:00 0.00% php-cgi 883 www 1 510 27656K 14708K accept 1 0:00 0.00% php-cgi 876 www 1 510 27656K 14480K accept 0 0:00 0.00% php-cgi 878 www 1 510 27656K 14480K accept 0 0:00 0.00% php-cgi 873 www 1 510 27656K 14480K accept 1 0:00 0.00% php-cgi 880 www 1 520 27656K 14884K accept 0 0:00 0.00% php-cgi 882 www 1 510 27656K 14708K accept 1 0:00 0.00% php-cgi 885 www 1 510 27656K 14708K accept 1 0:00 0.00% php-cgi Como podem perceber acima o servidor esta com memória, hard drive e cpu com disponibilidade considerável, mas detectamos que
Re: [pgbr-geral] Problema Query PostgreSQL 8.2.13 !!!
2009/12/4 Marcelo Barbosa marcelo.barb...@sizeof.com.br: Prezada Comunidade PostgreSQL, (...) * Problema: Ao executarmo a mesma query no servidor do cliente esta demora menos de 02:30 minutos já no cenário apresentado esta demorando mais de 03:30, sendo assim segue a forma que estamos executando a query: Você poderia nos enviar um EXPLAIN ANALYZE desta consulta em ambos os ambientes? Ao analisarmos o consumo dos recursos do servidor notamos o seguinte problema: |_r...@cliente: 10:29:51 ~_| top last pid: 37984; load averages: 0.63, 0.18, 0.06 up 0+05:38:26 10:30:59 46 processes: 2 running, 44 sleeping CPU: 49.2% user, 0.0% nice, 0.8% system, 0.4% interrupt, 49.6% idle Mem: 105M Active, 18M Inact, 92M Wired, 228K Cache, 81M Buf, 1783M Free Swap: 8192M Total, 8192M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 37982 pgsql 1 118 0 115M 49708K CPU1 1 1:01 100.00% postgres (...) Suponho que o servidor em questão possua dois núcleos certo? Como podem perceber acima o servidor esta com memória, hard drive e cpu com disponibilidade considerável, mas detectamos que somente um processo: postgresql 37982 esta com 100% de uso, mesmo tendo recursos no equipamento disponíveis, parecendo que o PostgreSQL não esta utilizando o recurso de THREAD, pois outros 03 processos postgresql estão utilizando 0% de recursos, Mesmo que utilizasse thread rodar executar *uma consulta especifica* em diferentes processadores implicaria em um processamento paralelo dos nós escolhidos pelo planejador, o quê não existe hoje no PostgreSQL. algum integrante já passou por este problema ? como podemos liberar para este processo um uso maior de recursos do servidor, ou mesmo liberar mais de um processo para a mesma query, no estilo THREAD, desde já obrigado pela atenção de todos. Precisamos de mais dados sobre a consulta em questão e sobre configurações do ambiente. []s Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] ERROR: out of memory Failed on request of size 88.
2009/12/4 Tiago Adami adam...@gmail.com 2009/12/4 Marcelo Costa marcelojsco...@gmail.com: Olá 2009/12/4 Tiago Adami adam...@gmail.com Estou executando uma rotina de reprocessamento na minha máquina, que roda Windows Vista Home Premium 32-bit e PostgreSQL 8.4.1. Com o mesmo database em um servidor de produção rodando Ubuntu Linux 8.04 32-bit e PostgreSQL 8.2.12, o erro não acontece. A rotina é na aplicação, executando mais de 50.000 comandos SQL dentro da transação (distribuídos entre INSERTS, UPDATES, DELETES e SELECTS). Chega um momento que o PostgreSQL simplesmente abre as pernas. A máquina fica impossível de ser utilizada, e logo em seguida a mensagem de erro é retornada pela aplicação: [SQL Error] Connectivity error: [SQL State] 53200 [Mensagem do driver ODBC] ERROR: out of memory Failed on request of size 88.; Error while executing the query [Código SQL] SELECT * FROM PCCMESD0 WHERE EMPFIL='0012' AND ITEM='414719' AND DTMOVI='2009-11-27' O que poderia ser? Seria este algum bug da 8.4.1 ou um bom motivo para usar Linux? ;) Nunca é tarde... No entanto não deveria ocorrer isso. Você poderia enviar os logs do banco de dados quando esse problema ocorre ? Qual o nível de log seria suficiente para este caso? (DEBUG1, DEBUG2, etc). No log consta apenas registros do tipo: CurTransactionContext: 8192 total in 1 blocks; 8176 free (1 chunks); 16 used DEBUG3 e veja o que ele reporta -- Marcelo Costa www.marcelocosta.net - “You can't always get what want”, Doctor House in apology to Mike Jagger ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] could not access status of transaction
JacksonWeber escreveu: ERROR: could not access status of transaction 1397965136 DETAIL: could not open file D:/work/data_pa/pg_clog/0535: No such file or directory Quais os arquivos estão no pg_clog e seus respectivos tamanhos? Se não há arquivos com nome próximo a 0535, você pode estar sofrendo de problemas na memória ou disco; verifique após conseguir recuperar os dados. Você precisa criar esse arquivo que o PostgreSQL _não_ está encontrando. cd $PGDATA/pg_clog dd if=/dev/zero of=0535 bs=8k count=1 Depois disso tente iniciar o PostgreSQL e, caso apareça outro mensagem, relate-a aqui. -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Query PostgreSQL 8.2.13 !!!
Prezados, Agradeço a rápida resposta, conforme o colega Marcelo Costa executei o solicitado e segue abaixo: last pid: 39893; load averages: 0.93, 0.48, 0.28 up 0+06:47:31 11:40:04 22 processes: 2 running, 20 sleeping CPU: 49.5% user, 0.0% nice, 0.4% system, 0.6% interrupt, 49.5% idle Mem: 88M Active, 17M Inact, 97M Wired, 212K Cache, 92M Buf, 1797M Free Swap: 8192M Total, 8192M Free PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 39879 pgsql 1 1180 118M 52276K CPU11 2:36 100.00% postgres: banco tabela [local] SELECT (postgres) 39704 pgsql 1 440 84480K 12084K select 0 0:00 0.00% postgres: writer process(postgres) 39702 pgsql 1 440 84480K 12060K select 1 0:00 0.00% /usr/local/bin/postgres -D /usr/local/pgsql/data 39705 pgsql 1 440 10400K 6480K select 0 0:00 0.00% postgres: stats collector process(postgres) Também conforme o colega Dickson, paramos todos os processos e serviços que não tem relação com o PostgreSQL, mas não obtivemos nenhuma diferença no resultado da query. Segue em anexo nosso postgresql.conf para análise de todos. Se existe mais alguma informação que seja necessária para análise da comunidade estamos a disposição, conforme o colega Dickson solicitou, EXPLAIN ANALYZE, não sabemos como executar, pois nosso conhecimento é mais focado em Data Center e não no banco de dados em si, mas comprometidos em auxiliar nosso cliente estamos em busca de uma solução para o mesmo, se for possível nos auxiliar estamos abertos, desde já obrigado a todos. Atenciosamente. Virtual Number: 160 São Paulo: +55 11 3711 5918 Porto Alegre: +55 51 3251 2616 Santa Cruz do Sul: +55 51 3056 9444 / +55 51 3056 4944 Fax: +55 51 3251 2615 Suporte: +55 51 8100 2280 marcelo.barb...@sizeof.com.br http://www.sizeof.com.br 2009/12/4 Dickson S. Guedes lis...@guedesoft.net 2009/12/4 Marcelo Barbosa marcelo.barb...@sizeof.com.br: Prezada Comunidade PostgreSQL, (...) * Problema: Ao executarmo a mesma query no servidor do cliente esta demora menos de 02:30 minutos já no cenário apresentado esta demorando mais de 03:30, sendo assim segue a forma que estamos executando a query: Você poderia nos enviar um EXPLAIN ANALYZE desta consulta em ambos os ambientes? Ao analisarmos o consumo dos recursos do servidor notamos o seguinte problema: |_r...@cliente: 10:29:51 ~_| top last pid: 37984; load averages: 0.63, 0.18, 0.06 up 0+05:38:26 10:30:59 46 processes: 2 running, 44 sleeping CPU: 49.2% user, 0.0% nice, 0.8% system, 0.4% interrupt, 49.6% idle Mem: 105M Active, 18M Inact, 92M Wired, 228K Cache, 81M Buf, 1783M Free Swap: 8192M Total, 8192M Free PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 37982 pgsql 1 1180 115M 49708K CPU11 1:01 100.00% postgres (...) Suponho que o servidor em questão possua dois núcleos certo? Como podem perceber acima o servidor esta com memória, hard drive e cpu com disponibilidade considerável, mas detectamos que somente um processo: postgresql 37982 esta com 100% de uso, mesmo tendo recursos no equipamento disponíveis, parecendo que o PostgreSQL não esta utilizando o recurso de THREAD, pois outros 03 processos postgresql estão utilizando 0% de recursos, Mesmo que utilizasse thread rodar executar *uma consulta especifica* em diferentes processadores implicaria em um processamento paralelo dos nós escolhidos pelo planejador, o quê não existe hoje no PostgreSQL. algum integrante já passou por este problema ? como podemos liberar para este processo um uso maior de recursos do servidor, ou mesmo liberar mais de um processo para a mesma query, no estilo THREAD, desde já obrigado pela atenção de todos. Precisamos de mais dados sobre a consulta em questão e sobre configurações do ambiente. []s Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral postgresql.conf Description: Binary data ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] mamooth / objectRMMS
Rudinei Dias escreveu: Dúvida sobre replicação master-slave: - esta pode ser bidirecional, ou seja, ocorrer alguma atualzação/inserção no slave e ser replicada no master, ou obrigatoriamente não? Não. Mestre-Escravo quer dizer que *somente* o mestre recebe atualizações e as repassa aos escravos. -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] PostgreSQL: Interoperabilidade com Oracl e em aplicação Java
Me desculpem por este assunto, gostaria de discutí-lo aqui na lista já que percebi existirem profissionais que trabalham com Java e PostgreSQL. Tenho um projeto para ser desenvolvido a longo prazo, um ERP. As exigências são que o programa funcione pelo menos com dois bancos de dados: Oracle e PostgreSQL (o cliente escolhe) e que as regras de negócio sejam escritas em Java (já que esta plataforma será usada em todo o resto do aplicativo). Eu tenho um certo receio em utilizar EJB devido à complexidade e pouca produtividade que esta arquitetura proporciona. O mesmo vale para o uso da JPA com Hibernate, Toplink ou qualquer outro framework de persistência, contando também que já tive muita dor de cabeça no passado em alguns projetos devido à incompatibilidade de algumas classes persistentes com estes dois bancos, tendo que fazer workarounds para colocá-los em funcionamento (principalmente com chaves primárias compostas por mais de uma coluna no banco). Pensei em usar Pl/Java (a exemplo de softwares como Adempière) ou alguma outra estratégia de persistência como DAO (!) ou até mesmo um framework que eu criei usando reflections para abstrair a criação e execução de códigos SQL. Mas antes de começar gostaria de ter uma opinião de quem trabalha com PostgreSQL e Java, com o quê vocês trabalham, já que preciso manter a interoperabilidade com estes bancos e também disponibilizar o acesso às regras de negócio para a Web e para Desktop. Em outros projetos grandes que trabalhei, a receita padrão do Java EE pouco ou nada utilizada... a persistência era gerida diretamente com SQL estático dentro de classes ou mesmo com o uso de DAO, por isso pouco acredito em EJB e JPA... Então, o que vocês sugerem? -- TIAGO J. ADAMI http://www.adamiworks.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Query PostgreSQL 8.2.13 !!!
Marcelo Barbosa escreveu: conforme o colega Dickson solicitou, EXPLAIN ANALYZE, não sabemos como executar Basta colocar EXPLAIN ANALYZE antes da consulta. EXPLAIN ANALYZE SELECT a, b FROM foo INNER JOIN bar ON (x = y); -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema Query PostgreSQL 8.2.13 !!!
2009/12/4 Marcelo Barbosa marcelo.barb...@sizeof.com.br Prezados, Agradeço a rápida resposta, conforme o colega Marcelo Costa executei o solicitado e segue abaixo: last pid: 39893; load averages: 0.93, 0.48, 0.28 up 0+06:47:31 11:40:04 22 processes: 2 running, 20 sleeping CPU: 49.5% user, 0.0% nice, 0.4% system, 0.6% interrupt, 49.5% idle Mem: 88M Active, 17M Inact, 97M Wired, 212K Cache, 92M Buf, 1797M Free Swap: 8192M Total, 8192M Free PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 39879 pgsql 1 1180 118M 52276K CPU11 2:36 100.00% postgres: banco tabela [local] SELECT (postgres) 39704 pgsql 1 440 84480K 12084K select 0 0:00 0.00% postgres: writer process(postgres) 39702 pgsql 1 440 84480K 12060K select 1 0:00 0.00% /usr/local/bin/postgres -D /usr/local/pgsql/data 39705 pgsql 1 440 10400K 6480K select 0 0:00 0.00% postgres: stats collector process(postgres) Também conforme o colega Dickson, paramos todos os processos e serviços que não tem relação com o PostgreSQL, mas não obtivemos nenhuma diferença no resultado da query. Segue em anexo nosso postgresql.conf para análise de todos. Se existe mais alguma informação que seja necessária para análise da comunidade estamos a disposição, conforme o colega Dickson solicitou, EXPLAIN ANALYZE, não sabemos como executar, pois nosso conhecimento é mais focado em Data Center e não no banco de dados em si, mas comprometidos em auxiliar nosso cliente estamos em busca de uma solução para o mesmo, se for possível nos auxiliar estamos abertos, desde já obrigado a todos. Atenciosamente. Há um comando select ( 39879 pgsql 1 1180 118M 52276K CPU11 2:36 100.00% postgres: banco tabela [local] SELECT (postgres)) sendo executado e que está comendo toda a cpu. Provavelmente ele está impactando nas respostas para rodar um EXPLAIN ANALYZE acesse o banco de dados com o psql (psql -U postgres nome_do_banco) e execute o select do pid 39879 com o comando EXPLAIN antes: EXPLAIN ANALYZE SELECT .. (entendeu ?) Eu sugiro chamar alguém de banco de dados para ajudar pois isso exigirá alguma configuração e análise. -- Marcelo Costa www.marcelocosta.net - “You can't always get what want”, Doctor House in apology to Mike Jagger ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] OFF-TOPIC [Fwd: Informações s obre a Campus Party Brasil 2010]
Àqueles que tiverem interesse... Mensagem original Olá a todos! Sejam muito bem vindos a Campus Party Brasil, o maior evento de inovação tecnológica, Internet e entretenimento eletrônico em rede do mundo. De 25 a 31 de janeiro de 2010, realizaremos a terceira edição da Campus Party no Brasil, no Centro de Exposições Imigrantes, em São Paulo. os participantes mudam-se com seus computadores, malas e barracas para dentro de uma arena, onde se conectam a uma rede super veloz e participam de oficinas, palestras, conferências, competições e diversas atividades ligadas ao mundo digital. Neste link você pode ver um vídeo sobre a Campus PArty Brasil 2009 *http://www.youtube.com/watch?v=gHkNNnX7HNk* Como podem ver, somos loucos por tecnologia! Algumas informações importantes: * As submissões de palestras, oficinas e outras atividades para área de software livre já estão abertas. Você pode fazer sua submissão em *http://tinyurl.com/yjmxky3* * Você pode colocar um dos banners promocionais do evento, eles estão disponíveis em *http://www.campus-party.com.br/tl_files/download/banners.zip* * A partir da próxima segunda-feira, 07/12/09, estará no ar uma promoção que vai distribuir ingressos para a Campus Party Brasil 2010. Enviarei o link a todos vocês na segunda-feira pela manhã. Por favor divulguem estas informações em suas comunidades e todos os canais de comunicação que julgarem pertinentes. Abraços. -- Vitório Sassi -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] ERROR: out of memory Failed on request of size 88.
2009/12/4 Marcelo Costa marcelojsco...@gmail.com:
2009/12/4 Tiago Adami adam...@gmail.com
2009/12/4 Marcelo Costa marcelojsco...@gmail.com:
Olá
2009/12/4 Tiago Adami adam...@gmail.com
Estou executando uma rotina de reprocessamento na minha máquina, que
roda Windows Vista Home Premium 32-bit e PostgreSQL 8.4.1. Com o mesmo
database em um servidor de produção rodando Ubuntu Linux 8.04 32-bit e
PostgreSQL 8.2.12, o erro não acontece.
A rotina é na aplicação, executando mais de 50.000 comandos SQL dentro
da transação (distribuídos entre INSERTS, UPDATES, DELETES e SELECTS).
Chega um momento que o PostgreSQL simplesmente abre as pernas. A
máquina fica impossível de ser utilizada, e logo em seguida a mensagem
de erro é retornada pela aplicação:
[SQL Error]
Connectivity error:
[SQL State]
53200
[Mensagem do driver ODBC]
ERROR: out of memory
Failed on request of size 88.;
Error while executing the query
[Código SQL]
SELECT * FROM PCCMESD0 WHERE EMPFIL='0012' AND ITEM='414719' AND
DTMOVI='2009-11-27'
O que poderia ser? Seria este algum bug da 8.4.1 ou um bom motivo para
usar Linux? ;)
Nunca é tarde...
No entanto não deveria ocorrer isso. Você poderia enviar os logs do
banco de
dados quando esse problema ocorre ?
Qual o nível de log seria suficiente para este caso? (DEBUG1, DEBUG2,
etc). No log consta apenas registros do tipo:
CurTransactionContext: 8192 total in 1 blocks; 8176 free (1 chunks); 16
used
DEBUG3 e veja o que ele reporta
Mais um erro, provavelmente com a mesma causa:
[SQL Error]
Connectivity error:
[SQL State]
25P02
[Mensagem do driver ODBC]
ERRO: transação atual foi interrompida,comandos ignorados até o fim do
bloco de transação;
Error while executing the query
[Código SQL]
INSERT INTO PCITESDA(EMPFIL,ITEM,SLD_FIS,SLD_INV,SLD_RES) VALUES
('0002','338575',41,000,41,000,0,000)
O log não diz muita coisa no momento do erro:
--
MdSmgr: 8192 total in 1 blocks; 5440 free (0 chunks); 2752 used
LOCALLOCK hash: 24576 total in 2 blocks; 16168 free (4 chunks); 8408 used
Timezones: 79320 total in 2 blocks; 5968 free (0 chunks); 73352 used
ErrorContext: 398800 total in 4 blocks; 23496 free (25 chunks); 375304 used
2009-12-04 11:40:12 BRTERROR: out of memory
2009-12-04 11:40:12 BRTDETAIL: Failed on request of size 1496789.
2009-12-04 11:40:14 BRTERRO: transação atual foi interrompida,
comandos ignorados até o fim do bloco de transação
2009-12-04 11:40:14 BRTCOMANDO: INSERT INTO
PCITESDA(EMPFIL,ITEM,SLD_FIS,SLD_INV,SLD_RES) VALUES (E'0002'
,E'338575' ,'41'::float8 ,'41'::float8 ,'0'::float8 )
2009-12-04 11:40:14 BRTERRO: transação atual foi interrompida,
comandos ignorados até o fim do bloco de transação
2009-12-04 11:40:14 BRTCOMANDO: insert into pchissql (programa, opid,
sql, tmp_exec) values (E'SSPLUSAPP' , E'SSP' , TRIM(E'INSERT INTO
PCITESDA(EMPFIL,ITEM,SLD_FIS,SLD_INV,SLD_RES) VALUES
(?cEmpfil,?cItem,?nSLD_FIS,?nSLD_INV,?nSLD_RES)' ), '0'::float8 )
Consegui contornar a situação diminuindo o tamanho das transações, ou
seja, como existe um laço de repetição entre cerca 20.000 registros
estou abrindo uma transação no início do laço e comitando ao seu
final.
A pergunta que fica agora é a seguinte: há como aumentar a
disponibilidade de memória para cada transação? O que fica claro aqui
é que uma única transação excede o máximo de memória permitido...
(agora está explicado porque no linux mesmo na versão 8.2 isso não
acontece: no servidor há 2 GB de RAM, e como não possui mais nada
rodando além dos serviços essenciais e o PostgreSQL, sobra memória).
--
TIAGO J. ADAMI
http://www.adamiworks.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Erro Drop table
Rodrigo Lang escreveu: Mateus, acho que o comando DROP TABLE public.car CASCADE; resolva seu problema... Ats, Rodrigo Lang. 2009/12/4 mateusgra mateusgra-I4oVjbygTnVfyO9Q7EP/y...@public.gmane.org mailto:mateusgra-I4oVjbygTnVfyO9Q7EP/y...@public.gmane.org DROP TABLE public.car; ERROR: con_pkey is an index A tabela car tem uma fk para tabela con. Ja tentei deletar a fk primeiro tb deu o mesmo erro. -- View this message in context: http://old.nabble.com/Erro-Drop-table-tp26635867p26635867.html Sent from the PostgreSQL - Brasil mailing list archive at Nabble.com. ___ pgbr-geral mailing list pgbr-geral-b/urxocn8+hhl2p70bp...@public.gmane.orgstgresql.org.br mailto:pgbr-geral-b/urxocn8+hxqfz5go68majmpyqws...@public.gmane.org https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Rodrigo F. Lang Amd. de Redes em Telecom http://langtechnologies.blogspot.com/ ___ pgbr-geral mailing list pgbr-geral-b/urxocn8+hxqfz5go68majmpyqws...@public.gmane.org https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Ja tentei o cascade. E agora tentei remover a CONSTRAINT: ALTER TABLE car DROP CONSTRAINT fk_car_con o erro continua. ___ 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 Drop table
2009/12/4 Mateus gra mateus...@bol.com.br: (corte) Ja tentei o cascade. E agora tentei remover a CONSTRAINT: ALTER TABLE car DROP CONSTRAINT fk_car_con o erro continua. Você poderia passar a estrutura dessa tabela public.car? É bem fácil através do pgAdmin apenas clique sobre a tabela que no quadro à direita todo o seu script de criação fica visível. Poste este script aqui para que possamos analisar melhor. -- TIAGO J. ADAMI http://www.adamiworks.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] could not access status of transaction
2009/12/4 Euler Taveira de Oliveira eu...@timbira.com: JacksonWeber escreveu: ERROR: could not access status of transaction 1397965136 DETAIL: could not open file D:/work/data_pa/pg_clog/0535: No such file or directory Quais os arquivos estão no pg_clog e seus respectivos tamanhos? Se não há arquivos com nome próximo a 0535, você pode estar sofrendo de problemas na memória ou disco; verifique após conseguir recuperar os dados. Você precisa criar esse arquivo que o PostgreSQL _não_ está encontrando. cd $PGDATA/pg_clog dd if=/dev/zero of=0535 bs=8k count=1 Apenas lembrando que é Windows. []s Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Erro Drop table
Tiago Adami escreveu: 2009/12/4 Mateus gra mateusgra-I4oVjbygTnVfyO9Q7EP/y...@public.gmane.org: (corte) Ja tentei o cascade. E agora tentei remover a CONSTRAINT: ALTER TABLE car DROP CONSTRAINT fk_car_con o erro continua. Você poderia passar a estrutura dessa tabela public.car? É bem fácil através do pgAdmin apenas clique sobre a tabela que no quadro à direita todo o seu script de criação fica visível. Poste este script aqui para que possamos analisar melhor. CREATE TABLE car ( carid serial NOT NULL, carcon integer NOT NULL, cardesc character varying(80), CONSTRAINT fk_car_con FOREIGN KEY (carcon) REFERENCES con (conid) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION ) WITH ( OIDS=FALSE ); ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] could not access status of transaction
Dickson S. Guedes escreveu: Apenas lembrando que é Windows. Existe dd para Windows. -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Erro Drop table
2009/12/4 Mateus gra mateus...@bol.com.br: Tiago Adami escreveu: 2009/12/4 Mateus gra mateusgra-I4oVjbygTnVfyO9Q7EP/y...@public.gmane.org: (corte) Ja tentei o cascade. E agora tentei remover a CONSTRAINT: ALTER TABLE car DROP CONSTRAINT fk_car_con o erro continua. Você poderia passar a estrutura dessa tabela public.car? É bem fácil através do pgAdmin apenas clique sobre a tabela que no quadro à direita todo o seu script de criação fica visível. Poste este script aqui para que possamos analisar melhor. CREATE TABLE car ( carid serial NOT NULL, carcon integer NOT NULL, cardesc character varying(80), CONSTRAINT fk_car_con FOREIGN KEY (carcon) REFERENCES con (conid) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION ) WITH ( OIDS=FALSE ); Esse erro já fugiu do meu conhecimento. Criei uma tabela con e a tabela car conforme o script enviado pelo Mateus da seguinte forma: CREATE TABLE con( conid INTEGER not null primary key ); CREATE TABLE car ( carid serial NOT NULL, carcon integer NOT NULL, cardesc character varying(80), CONSTRAINT fk_car_con FOREIGN KEY (carcon) REFERENCES con (conid) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION ) WITH ( OIDS=FALSE ); Depois rodei o comando: DROP TABLE car; E nenhum erro ocorreu. Estou usando a versão 8.4.1. Qual a sua, Mateus? -- TIAGO J. ADAMI http://www.adamiworks.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
