Fabio, Euler e Tiago. Muito obrigado pelas explanações, realmente me ajudaram muito, principalmente no que se refere a embassar a necessidade de melhoria do hardware junto ao cliente, que nesse caso é tudo "xiruzão". Ja revisei o hardware do outro servidor e o mesmo tbm apresentou falhas na memória e na fonte... Quanto ao depoimento do Tiago e os comentários do Euler, acho que contribuiram muito não só para meu problema mas também em outros aspectos interessantes.
Obrigado a todos! Julio Tofoli SetaDigital Sistemas -------------------------------------------------- From: "Euler Taveira de Oliveira" <[email protected]> Sent: Wednesday, February 23, 2011 9:07 PM To: <[email protected]> Subject: Re: [pgbr-geral] Erro em tabela/registro: "Invalid memory allocrequest size > Em 23-02-2011 20:10, Tiago Adami escreveu: >> Mas... mesmo com hardwares como HP e Dell alguns servidores de >> clientes que rodam Windows 2003 e 2008 e a mesma versão do PostgreSQL >> que citei acima já tiveram vários problemas com logs e registros de >> tabelas corrompidos (coisa que era fácil eliminar com o DBUtil para >> DBF hehehe). >> > Os problemas emergem de várias frentes (mas não são limitados a essas): > > (i) o port para plataforma Windows é recente: a quantidade de bugs em uma > plataforma recém suportada é muito maior nesta plataforma do que nas que > já > são suportadas a vários anos (UNIX-like); > (ii) o Windows não implementa uma API padronizada: os caminhos para > execução > de algumas rotinas são totalmente diferentes das plataformas já > suportadas. > Assim, a probabilidade de bugs é muito maior; > (iii) a M$ não atualiza a documentação de sua API: o uso de algumas > rotinas da > API têm um comportamento totalmente obscuro. Assim, vários bugs são > detectados > mas, às vezes, demoram muito tempo para serem corrigidos porque os > desenvolvedores não conseguem reproduzí-los ou mesmo, encontrar respostas > na > documentação fornecida; > (iv) o Windows não oferece opções seguras para SGBDs: em algumas versões > do > Windows (para desktops), as opções de escrita segura não são o padrão > (porque > degradam muito a performance?). Muitas dessas versões são usadas para > colocar > um PostgreSQL em produção (é claro que desaconselhamos isso severamente > mas > alguns usuários insistem?!). > >> A boa notícia é que, em todos os servidores Linux e Unix rodando >> PostgreSQL que eu tive contato, nunca precisei realizar operações de >> recovery,e nunca vi problemas parecidos. O pessoal me critica muito >> quando falo isso, mas IMNSHO Windows e PostgreSQL não combinam. Talvez >> a versão paga da EnterpriseDB... >> > Windows e PostgreSQL combinam sim. Basta utilizar o SO apropriado (Windows > Server -- XP, Vista: não obrigado!) com a última versão do PostgreSQL (9.0 > atualmente). As melhorias das rotinas específicas para Windows no código > do > PostgreSQL continuam. Posso dizer que as rotinas específicas estão bem > estáveis agora do que a uns três anos atrás (aka 8.2). > > O código do EDB está alinhado com o código da comunidade atualmente; > salvo, o > negócio deles: funcionalidades semelhantes as do Oracle. A alguns anos > atrás > eles implementaram funcionalidades que não estavam no core mas chegaram a > conclusão de que a mantenabilidade de tais funcionalidades fogem ao escopo > do > negócio deles e não vale o esforço. O que eles fazem atualmente é > contribuir > essas funcionalidades ao projeto ao invés de mantê-las fechadas. Nós > ganhamos > e eles também (com melhorias). > > > -- > Euler Taveira de Oliveira > http://www.timbira.com/ > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
