Quando é encontrado algum erro no PostgreSQL nós desejamos conhecê-lo. Seus relatórios de erro são parte importante para tornar o PostgreSQL mais confiável, porque mesmo o mais extremo cuidado não pode garantir que todas as partes do PostgreSQL vão funcionar em todas as plataformas sob qualquer circunstância.
As sugestões abaixo têm por objetivo ajudá-lo a preparar seu relatório de erro, permitindo que este possa ser tratado de uma forma efetiva. Ninguém é obrigado a segui-las, mas são feitas para serem vantajosas para todos.
Nós 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 olhá-lo. Pode acontecer, também, nós solicitarmos a atualização 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 uma grande reescrita que planejamos fazer. Ou, talvez, é simplesmente muito difícil corrigi-lo 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.
Antes de relatar 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 está claro na documentação que algo pode ou não ser feito, por favor informe isto também; é um erro da documentação. Se acontecer do programa fazer algo diferente do que está escrito na documentação, isto também é um erro. Pode incluir, mas não está restrito às seguintes circunstâncias:
O programa termina com um erro fatal, ou com uma mensagem de erro do sistema operacional que aponta para um erro no programa (um exemplo oposto seria uma mensagem de "disco cheio", porque o próprio usuário deve corrigir este problema).
O programa produz uma saída errada para uma entrada específica.
O programa se recusa a aceitar uma entrada válida (conforme definido na documentação).
O programa aceita uma entrada inválida sem enviar uma mensagem de erro. Porém, tenha em mente que a sua idéia de entrada errada pode ser a nossa idéia de uma extensão, ou a compatibilidade com a prática tradicional.
O PostgreSQL falha ao compilar, montar ou instalar de acordo com as instruções, em uma plataforma suportada.
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 alguma lista de discussão pedindo ajuda para ajustar suas aplicações. Não agir de acordo com o padrão SQL também não é necessariamente um erro, a não ser que a aderência com a funcionalidade específica esteja explicitamente declarada.
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 mais importante a ser lembrado quando relatamos erros é declarar todos os fatos, e somente os fatos. Não especule sobre o que você acha que está certo ou errado, o que "parece que deva ser feito", ou qual parte do programa está falhando. Se você não está 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 explanação educada é um grande suplemento, mas não substitui os fatos. Se nós formos corrigir o erro, nós temos que vê-lo acontecer primeiro. Informar fatos cruamente é relativamente direto (provavelmente pode ser copiado e colado a partir da tela), mas geralmente detalhes importantes são deixados de fora porque alguém pensou que não tinha importância, ou que o relatório seria entendido de qualquer forma.
Os seguintes itens devem estar contidos em todo relatório de erro:
A seqüência exata dos passos, desde o início do programa, necessários para reproduzir o problema. Isto deve estar autocontido; não é suficiente enviar apenas um comando SELECT sem enviar os comandos CREATE TABLE e INSERT que os precederam, se a saída depender dos dados contidos nas tabelas. Nós não temos tempo para realizar a engenharia reversa do esquema do seu banco de dados e, se nós tivermos que criar os nossos próprios dados, nós provavelmente não vamos conseguir reproduzir o problema. O melhor formato para realizar um caso de teste, para problemas associados à linguagem de consulta, é um arquivo que possa ser executado a partir da aplicação psql e que mostre o problema (certifique-se que não existe nada em seu arquivo de inicialização ~/.psqlrc). Um modo fácil de começar este arquivo é usar o pg_dump para gerar as declarações da tabela e dos dados necessários para montar o cenário, e depois incluir a consulta problemática. Encorajamos você a minimizar o tamanho do exemplo, mas isto não é absolutamente necessário. Se o erro for reproduzível, nós o encontraremos de qualquer forma.
Se o sua aplicação utiliza alguma outra interface no cliente tal como o PHP então, por favor, tente isolar a consulta problemática. Provavelmente nós não vamos configurar um servidor Web para reproduzir seu problema. De qualquer forma, lembre-se de fornecer os arquivos de entrada exatos, e não suponha que o problema aconteça com "arquivos grandes" ou "bancos de dados de tamanho médio", etc. porque estas informações são muito pouco precisas para serem utilizadas.
A saída produzida. Por favor, não diga que "não funcionou" ou que "deu pau". Havendo uma mensagem de erro mostre-a, mesmo que você não consiga entendê-la. Se o programa terminar com um erro do sistema operacional, diga qual. Se nada acontecer, informe. Mesmo que o resultado do seu caso de teste seja o término anormal do programa, ou seja óbvio de alguma outra forma, pode ser que isto não aconteça em nossa plataforma. O mais fácil a ser feito é copiar a saída do terminal, quando possível.
Nota: No caso de erros fatais a mensagem de erro informada pelo cliente pode não conter toda a informação disponível. Por favor, olhe também o log produzido no servidor de banco de dados. Se você não mantém a saída do log do servidor, esta é uma boa hora para começar a fazê-lo.
A saída esperada é uma informação importante a ser declarada. Se você escreve apenas "Este comando produz esta saída." ou "Isto não é o que eu esperava.", nós podemos executar, olhar a saída, e achar que está tudo correto e é exatamente o que nós esperávamos que fosse. Nós não temos que perder tempo para decodificar a semântica exata por trás de seus comandos. Abstenha-se especialmente de dizer meramente "Isto não é o que o SQL diz ou o que o Oracle faz". Pesquisar o comportamento correto do SQL não é uma tarefa divertida, nem nós sabemos como todos os outros bancos de dados relacionais existentes se comportam (se seu problema é o término anormal do seu programa, este item obviamente pode ser omitido).
Qualquer opção de linha de comando e outras opções de inicialização, incluindo as variáveis de ambiente relacionadas ou arquivos de configuração que foram alterados em relação ao padrão. Novamente, seja exato. Se estiver sendo utilizada uma distribuição pré-configurada que inicializa o servidor de banco de dados durante o boot, deve-se tentar descobrir como isto é feito.
Qualquer coisa feita diferente das instruções de instalação.
A versão do PostgreSQL. Pode ser executado o comando SELECT version(); para descobrir a versão do servidor ao qual se está conectado. A maioria dos programas executáveis suporta a opção --version; ao menos postmaster --version e psql --version devem funcionar. Se a função ou as opções não existirem, então a versão sendo usada é muito antiga e merece ser atualizada. Também pode ser visto o arquivo README no diretório do fonte, ou o arquivo com o nome da distribuição ou o nome do pacote. Se a versão for pré-configurada, como RPMs, informe, incluindo qualquer sub-versão que o pacote possa ter. Se estiver se referindo a uma versão do CVS isto deve ser mencionado, incluindo a data e a hora.
Se sua versão for anterior a 7.3.4 provavelmente nós lhe pediremos que atualize. Existem toneladas de correções de erro a cada nova liberação, sendo este o motivo das novas liberações.
Informações da plataforma. Isto inclui o nome do núcleo e a versão, a biblioteca C, o processador e a memória. Na maioria dos casos é suficiente informar o fornecedor e a versão, mas não se deve supor que todo mundo sabe exatamente o que o "Debian" contém, ou que todo mundo use Pentium. Havendo problemas de instalação, então as informações sobre compilador, make, etc. também são necessárias.
Não tenha medo que seu relatório de erro se torne muito longo. Este é um fato da vida. É melhor relatar tudo da primeira vez do que nós 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 resolver o problema. Se for visto que o erro não pode ser corrigido imediatamente, você ainda vai ter tempo para compartilhar sua descoberta com os outros. Também, novamente, não perca seu tempo adivinhando porque o erro existe. Nós o encontraremos brevemente.
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 abreviar. Se estiver se referindo especificamente ao processo servidor mencione isto, não diga apenas que 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 terminal interativo "psql", são completamente separados do servidor. Por favor, tente especificar se o problema está no lado do cliente ou no lado do servidor.
De modo geral, os relatórios de erro devem ser enviados para a lista de
discussão de relatórios de erros em <pgsql-bugs@postgresql.org>.
É necessária a utilização de um assunto descritivo para a mensagem de correio
eletrônico, talvez uma parte da própria mensagem de erro.
Outro método é preencher o relatório de erro disponível
no sítio do projeto na Web em
http://www.postgresql.org/.
O preenchimento desta forma faz com que seja enviado para
a lista de discussão <pgsql-bugs@postgresql.org>.
Não envie o relatório de erro para nenhuma lista de discussão dos usuários,
tal como <pgsql-sql@postgresql.org> ou
<pgsql-general@postgresql.org>.
Estas listas de discussão são para responder perguntas
dos usuários, e seus subscritores 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 <pgsql-hackers@postgresql.org>.
Esta lista é para discutir o desenvolvimento
do PostgreSQL e nós gostamos
de manter os relatórios de erro em separado. Nós podemos decidir
discutir seu relatório de erro em
pgsql-hackers, se o problema necessitar uma maior averiguação.
Se você tiver problema com a documentação, o melhor lugar para relatar
é na lista de discussão da documentação em <pgsql-docs@postgresql.org>.
[1]
Por favor, seja específico sobre qual parte da documentação você está descontente.
Se seu erro for algum problema de portabilidade ou uma plataforma não suportada,
envie uma mensagem de correio eletrônico para <pgsql-ports@postgresql.org>,
para que nós (e você) possamos trabalhar para portar
o PostgreSQL para esta plataforma.
Nota: Devido à 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, você precisa subscrever a lista primeiro para depois poder enviar mensagens (entretanto, você não precisa subscrever 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
<majordomo@postgresql.org>contendo apenas a palavra help no corpo da mensagem.
| [1] | Informe os erros encontrados na tradução deste manual a
|