AltaVista
Google

Guia para informar erros

Quando for encontrado algum erro no PostgreSQL desejamos ser informados. Seus relatórios de erro são importantes para tornar o PostgreSQL mais confiável, porque mesmo o cuidado mais extremo não pode garantir que todas as partes do PostgreSQL funcionam em todas as plataformas sob qualquer circunstância.

As sugestões abaixo têm por objetivo ajudá-lo a preparar relatórios de erro que possam ser tratados de forma eficaz. Ninguém é obrigado a segui-las, mas são feitas para serem vantajosas para todos.

Não podemos prometer corrigir todos os erros imediatamente. Se o erro for óbvio, crítico, ou afetar muitos usuários, existe uma boa chance de alguém investigá-lo. Pode acontecer, também, nós solicitarmos que você atualize para uma nova versão, para ver se o erro também acontece na nova versão. Também podemos decidir que o erro não poderá ser corrigido antes de ser feita uma importante reescrita planejada ou, talvez, simplesmente esta correção seja muito difícil e existem assuntos mais importantes na agenda. Se for necessária ajuda imediata, deve ser levada em consideração a contratação de um suporte comercial.

Identificação de erros

Antes de informar um erro, por favor leia e releia a documentação para verificar se realmente pode ser feito o que está se tentando fazer. Se não estiver claro na documentação se pode ou não ser feito, por favor informe isto também; é uma falha na documentação. Se for visto que o programa faz algo diferente do que está especificado na documentação, isto também é um erro. Pode incluir, sem estar restrito, as seguintes circunstâncias:

Aqui "programa" se refere a qualquer executável, e não apenas ao processo servidor.

Estar lento ou consumir muitos recursos não é necessariamente um erro. Leia a documentação ou faça perguntas em uma lista de discussão pedindo ajuda para ajustar seus aplicativos. Não agir em conformidade com o padrão SQL também não é necessariamente um erro, a não ser que a conformidade com a funcionalidade específica esteja explicitamente informada.

Antes de prosseguir, verifique a lista TODO (a fazer) e a FAQ para ver se o erro já não é conhecido. Se você não conseguir decodificar a informação da lista TODO, relate seu problema. O mínimo que podemos fazer é tornar a lista TODO mais clara.

O que informar

O mais importante a ser lembrado sobre informar erros é declarar todos os fatos, e somente os fatos. Não especule sobre o que você pensa que deu errado, o que "parece que deve ser feito", ou em que parte do programa está o erro. Se não estiver familiarizado com a implementação você provavelmente vai supor errado, e não vai nos ajudar nem um pouco. E, mesmo que você esteja familiarizado, uma explicação educada é um grande suplemento, mas não substitui os fatos. Se formos corrigir o erro, temos que vê-lo acontecer primeiro. Informar meramente os fatos é relativamente direto (provavelmente pode ser copiado e colado a partir da tela), mas geralmente são deixados de fora detalhes importantes porque se pensou que não tinham importância, ou que o relatório seria entendido de qualquer maneira.

Todo relatório de erro deve conter os seguintes itens:

Não tenha medo que seu relatório de erro fique muito longo. Este é um fato da vida. É melhor informar tudo da primeira vez do que termos que extrair os fatos de você. Por outro lado, se seus arquivos de entrada são enormes, é justo perguntar primeiro se alguém está interessado em vê-los.

Não perca seu tempo tentando descobrir que mudanças na entrada fazem o problema desaparecer. Isto provavelmente não vai ajudar a solucionar o problema. Se for visto que o erro não pode ser corrigido imediatamente, você vai ter tempo para descobrir e compartilhar sua descoberta. Também, novamente, não perca seu tempo adivinhando porque o erro existe, nós o descobriremos em breve.

Ao escrever o relatório de erro, por favor escolha uma terminologia que não confunda. O pacote de software em seu todo é chamado de "PostgreSQL" e, algumas vezes, de "Postgres" para encurtar. Se estiver se referindo especificamente ao processo servidor mencione isto, não diga apenas "o PostgreSQL caiu". A queda de um único processo servidor é bem diferente da queda do processo "postmaster" pai; por favor não diga "o postmaster caiu" quando um único processo servidor caiu, nem o contrário. Além disso os programas cliente, como o cliente interativo "psql", são completamente separados do servidor. Por favor, tente especificar se o problema está no lado cliente ou no lado servidor.

Onde informar os erros

De modo geral, envie relatórios de erro para a lista de discussão de relatórios de erros em . É necessário utilizar um assunto descritivo para a mensagem de correio eletrônico, talvez partes da própria mensagem de erro.

Outra forma é preencher o relatório de erro disponível no sítio do projeto na Web em http://www.postgresql.org/. Preencher o relatório de erro desta forma faz com que seja enviado para a lista de discussão .

Não envie o relatório de erro para nenhuma lista de discussão dos usuários, tal como ou . Estas listas de discussão são para responder as perguntas dos usuários, e seus assinantes normalmente não desejam receber relatórios de erro. Mais importante ainda, eles provavelmente não vão conseguir corrigir o erro.

Por favor, também não envie relatórios para a lista de discussão dos desenvolvedores em . Esta lista é para discutir o desenvolvimento do PostgreSQL, e gostamos de manter os relatórios de erro em separado. Podemos decidir discutir seu relatório de erro em pgsql-hackers, se o problema necessitar uma melhor averiguação.

Se você tiver problema com a documentação, o melhor lugar para informar é na lista de discussão da documentação em . [1] Por favor seja específico sobre qual parte da documentação você não está satisfeito.

Se seu erro for um problema de portabilidade em uma plataforma não suportada, envie uma mensagem de correio eletrônico para , para que nós (e você) possamos trabalhar para portar o PostgreSQL para esta plataforma.

Nota: Por causa da grande quantidade de spam na Internet, todos os endereços de correio eletrônico acima são de listas de discussão fechadas, ou seja, primeiro é necessário assinar a lista para depois poder enviar mensagens (entretanto, não é necessário assinar nenhuma lista para utilizar o formulário de relatório de erro da Web). Se você deseja enviar uma mensagem de correio eletrônico, mas não deseja receber o tráfego da lista, você pode subscrever e configurar sua opção de subscrição com nomail. Para maiores informações envie uma mensagem para contendo apenas a palavra help no corpo da mensagem.

Notas

[1]

Por favor, informe os erros de tradução encontrados nesta documentação para . (N. do T.)

SourceForge.net Logo CSS válido!