O comando que gera um ponto de verificação manual no banco de dados no instante da execução

Existem vários parâmetros de configuração que afetam o comportamento do sistema de banco de dados. Nesta seção é descrito como definir os parâmetros de configuração; as subseções abaixo discutem cada parâmetro em detalhe.

Não há diferença entre letras maiúsculas e minúsculas nos nomes dos parâmetros. Todo parâmetro aceita um valor de um destes quatro tipos: booleano, inteiro, ponto flutuante ou cadeia de caracteres. Os valores booleanos podem ser escritos como ON, OFF, TRUE, FALSE, YES, NO, 1 ou 0 (sem distinção entre letras maiúsculas e minúsculas), ou qualquer prefixo não ambíguo destes.

Uma forma de definir estes parâmetros é editar o arquivo postgresql.conf, normalmente presente no diretório de dados (O utilitário initdb instala uma cópia padrão neste diretório). Um exemplo de como este arquivo se parece é:

# Isto é um comentário
log_connections = yes
log_destination = 'syslog'
search_path = '$user, public'

É especificado um parâmetro por linha. O sinal de igual entre o nome e o valor é opcional. Espaços em branco não são significativos e as linhas em branco são ignoradas. O caractere cerquilha (#) insere comentário em qualquer posição. Os valores dos parâmetros, que não são identificadores simples ou números, devem estar entre apóstrofos (').

O arquivo de configuração é lido novamente sempre que o processo postmaster recebe do sistema o sinal SIGHUP (cuja forma mais fácil de enviar é através de pg_ctl reload). O postmaster também propaga este sinal para todos os processos servidor em execução, para que as sessões em andamento também leiam os novos valores. Como alternativa, o sinal pode ser enviado diretamente para um único processo servidor. Alguns parâmetros somente podem ser definidos durante a inicialização do servidor; qualquer modificação de seus valores no arquivo de configuração será ignorada até que o servidor seja reiniciado.

A segunda forma de definir estes parâmetros de configuração é fornecê-los como opção de linha de comando para o postmaster, como em:

postmaster -c log_connections=yes -c log_destination='syslog'

As opções de linha de comando têm precedência sobre qualquer definição conflitante presente no arquivo postgresql.conf. Deve ser observado que isto significa não ser possível alterar em tempo de execução um valor fornecido como opção de linha de comando editando o arquivo postgresql.conf. Portanto, embora o método linha de comando possa ser conveniente, pode causar perda de flexibilidade.

Ocasionalmente, também é útil fornecer uma opção de linha de comando para apenas uma determinada sessão. Para esta finalidade pode ser utilizada a variável de ambiente PGOPTIONS no lado cliente:

env PGOPTIONS='-c geqo=off' psql

(Funciona para todo aplicativo cliente baseado na biblioteca libpq, e não apenas para o psql). Deve ser observado que não funciona para os parâmetros que são fixados na inicialização do servidor, ou que devem ser especificados no arquivo postgresql.conf.

Além disso, é possível atribuir um conjunto de definições de parâmetro a um usuário ou a um banco de dados. Sempre que uma sessão é iniciada, as definições padrão para o usuário ou para o banco de dados são carregadas. Para configurar estas definições são utilizados os comandos ALTER USER e ALTER DATABASE, respectivamente. As definições para o banco de dados têm precedência sobre qualquer definição recebida pela linha de comando do postmaster ou através do arquivo de configuração. Por sua vez, as definições para o usuário têm precedência sobre as definições para o banco de dados; as opções para a sessão têm precedência sobre as duas.

Alguns parâmetros podem ser alterados nas sessões SQL individuais utilizando o comando SET como, por exemplo:

SET ENABLE_SEQSCAN TO OFF;

Se o comando SET for permitido, tem precedência sobre todas as outras fontes de valor para parâmetros. Alguns parâmetros não podem ser alterados através do comando SET: por exemplo, parâmetros que controlam um comportamento que não pode ser alterado sem reiniciar o PostgreSQL. Além disso, alguns parâmetros podem ser alterados através dos comandos SET ou ALTER pelos superusuários, mas não pelos usuários comuns.

O comando SHOW permite ver o valor corrente de todos os parâmetros.

A tabela virtual pg_settings (descrita na Seção 42.35) também permite ver e atualizar os parâmetros em tempo de execução da sessão. Equivale ao comando SHOW e SET, mas seu uso pode ser mais conveniente, porque pode ser feita a junção com outras tabelas, ou feita a seleção utilizando a condição de seleção desejada.

16.4.1. Locais dos arquivos

Além do arquivo postgresql.conf já mencionado, o PostgreSQL utiliza outros dois arquivos de configuração, editados manualmente, para controlar a autenticação de clientes, (estes arquivos são mostrados no Capítulo 19). Por padrão todos estes três arquivos de configuração são armazenados no diretório de dados do agrupamento de bancos de dados. Os parâmetros descritos nesta subseção permitem colocar os arquivos de configuração em outro local (Fazer isto pode facilitar a administração. Em particular, geralmente é mais fácil fazer a cópia de segurança dos arquivos de configuração quando estes são mantidos separados dos arquivos do diretório de dados).

data_directory (string)

Especifica o diretório a ser utilizado para armazenamento dos dados. Somente pode ser definido na inicialização do servidor.

Especifica o arquivo principal de configuração do servidor (geralmente chamado postgresql.conf). Somente pode ser definido na linha de comando do postmaster.

Especifica o arquivo de configuração para autenticação baseada no hospedeiro (normalmente chamado pg_hba.conf). Somente pode ser definido na inicialização do servidor.

Especifica o arquivo de configuração para a autenticação ident (normalmente chamado pg_ident.conf). Somente pode ser definido na inicialização do servidor.

Especifica o nome de um arquivo de identificação de processo adicional, que o postmaster deve criar para uso pelos programas de administração do servidor. Somente pode ser definido na inicialização do servidor.

Em uma instalação padrão, nenhum dos parâmetros acima é definido explicitamente. Em vez disso, o diretório de dados é especificado através da opção de linha de comando -D, ou através da variável de ambiente PGDATA, e os arquivos de configuração ficam todos no diretório de dados.

Se for desejado manter os arquivos de configuração em um local diferente do diretório de dados, então a opção de linha de comando -D do postmaster, ou a variável de ambiente PGDATA, deve apontar para o diretório que contém os arquivos de configuração, e o parâmetro data_directory deve estar definido no arquivo postgresql.conf (ou na linha de comando) para indicar onde o diretório de dados realmente se encontra. Deve ser observado que o parâmetro data_directory tem precedência sobre -D e sobre PGDATA para o local do diretório de dados, mas não para o local dos arquivos de configuração.

Se for desejado, podem ser especificados individualmente os nomes dos arquivos e seus locais utilizando os parâmetros config_file, hba_file e ident_file. O parâmetro config_file somente pode ser especificado na linha de comando do postmaster, mas os outros dois podem ser definidos no arquivo de configuração principal. Se, além de data_directory, estes outros três parâmetros forem definidos explicitamente, então não é necessário especificar -D ou PGDATA.

Quando uma destas três opções é definida, um caminho relativo é interpretado como sendo relativo ao diretório onde o postmaster é inicializado.

16.4.2. Conexões e Autenticação

16.4.2.1. Definições de conexão

listen_addresses (string)

Especifica o endereço, ou endereços, de TCP/IP onde o servidor atende as conexões dos aplicativos cliente. O valor tem a forma de uma lista de nomes de hospedeiros, ou de endereços numéricos de IP, separados por vírgula. A entrada especial * corresponde a todas as interfaces de IP disponíveis. Se a lista estiver vazia, o servidor não atende nenhuma interface IP e, neste caso, somente podem ser utilizados soquetes do domínio Unix para conectar ao servidor de banco de dados. O valor padrão é localhost, que permite serem feitas apenas conexões locais "retornantes" (loopback). Somente pode ser definido na inicialização do servidor.

A porta TCP onde o servidor está atendendo; 5432 por padrão. Deve ser observado que é utilizada a mesma porta em todos os endereços de IP onde o servidor atende. Somente pode ser definido na inicialização do servidor.

Determina o número máximo de conexões simultâneas ao servidor de banco de dados. O valor típico é 100, mas pode ser menor se a configuração do núcleo do sistema operacional não não tiver capacidade para suportar este valor (conforme determinado durante o initdb). Somente pode ser definido na inicialização do servidor.

O aumento deste parâmetro pode fazer com que o PostgreSQL requisite mais memória compartilhada System V que o permitido pela configuração padrão do sistema operacional. Para obter informações sobre como ajustar estes parâmetros deve ser consultada a Seção 16.5.1, se for necessário.

Determina o número de "encaixes de conexão" (connection slots), reservados para os superusuários do PostgreSQL se conectarem. Podem estar ativas até max_connections conexões simultâneas. Sempre que o número de conexões ativas simultâneas for igual ou maior a max_connections menos superuser_reserved_connections, somente serão aceitas novas conexões feitas por superusuários.

O valor padrão é 2. O valor deve ser menor que o valor de max_connections. Somente pode ser definido na inicialização do servidor.

Especifica o diretório do soquete do domínio Unix onde o servidor está atendendo as conexões dos aplicativos cliente. Normalmente o valor padrão é /tmp, mas pode ser mudado em tempo de construção. Somente pode ser definido na inicialização do servidor.

Define o grupo dono do soquete do domínio Unix (O usuário dono do soquete é sempre o usuário que inicializa o servidor). Combinado com o parâmetro unix_socket_permissions pode ser utilizado como um mecanismo de controle de acesso adicional para as conexões do domínio Unix. Por padrão é uma cadeia de caracteres vazia, que utiliza o grupo padrão do usuário corrente. Somente pode ser definido na inicialização do servidor.

Define as permissões de acesso do soquete do domínio Unix. Os soquetes do domínio Unix utilizam o conjunto usual de permissões do sistema de arquivos do Unix. Para o valor deste parâmetro, é esperada uma especificação de modo numérica, na forma aceita pelas chamadas de sistema chmod e umask (Para utilizar o formato octal, como é de costume, o número deve começar por 0 (zero)).

As permissões padrão são 0777, significando que qualquer um pode se conectar. Alternativas razoáveis são 0770 (somente o usuário e o grupo, consulte também unix_socket_group), e 0700 (somente o usuário); deve ser observado que, na verdade, para soquetes do domínio Unix somente a permissão de escrita tem importância, não fazendo sentido conceder ou revogar permissões de leitura e de execução.

Este mecanismo de controle de acesso é independente do descrito no Capítulo 19.

Somente pode ser definido na inicialização do servidor.

Especifica o nome de difusão (broadcast) Rendezvous. Por padrão é utilizado o nome do computador, especificado através de uma cadeia de caracteres vazia (''). É ignorado quando o servidor não é compilado com suporte a Rendezvous. Somente pode ser definido na inicialização do servidor.

16.4.2.2. Segurança e autenticação

authentication_timeout (integer)

Tempo máximo, em segundos, para completar a autenticação do cliente. Se a tentativa de tornar-se cliente não completar o protocolo de autenticação nesta quantidade de tempo, o servidor derruba a conexão. Isto impede que clientes travados fiquem ocupando a conexão indefinidamente. Somente pode ser definido na inicialização do servidor, ou no arquivo postgresql.conf. O valor padrão é 60.

Ativa conexões SSL. Por favor leia a Seção 16.7 antes de utilizar este parâmetros. O valor padrão é falso. Somente pode ser definido na inicialização do servidor.

Quando é especificada uma senha em CREATE USER ou ALTER USER, sem que seja escrito ENCRYPTED ou UNENCRYPTED, este parâmetro determina se a senha deve ser criptografada. O valor padrão é verdade (criptografar a senha).

Define o local do arquivo de chave do servidor Kerberos. Para obter detalhes deve ser consultada a Seção 19.2.3 .

Permite nomes de usuário por banco de dados. O valor padrão é falso.

Se o valor for verdade, os usuários devem ser criados como nome_do_usuário@nome_bd. Quando o nome_do_usuário é passado por um cliente se conectando, são anexados @ e o nome do banco de dados ao nome do usuário, então o servidor procura por este nome de usuário específico do banco de dados. Deve ser observado que, no ambiente SQL, para criar nomes de usuário contendo @ é necessário colocar o nome de usuário entre aspas.

Quando o valor deste parâmetro é verdade, ainda podem ser criados usuários globais comuns. Deve apenas ser anexado o caractere @ à especificação do nome de usuário no cliente. O caractere @ será retirado antes do nome de usuário ser procurado pelo servidor.

Nota: Esta funcionalidade foi criada como uma medida temporária até que seja encontrada uma solução definitiva, quando então será removida.

16.4.3. Consumo de recursos

16.4.3.1. Memória

shared_buffers (integer)

Define o número de buffers de memória compartilhada, utilizados pelo servidor de banco de dados. O valor típico é 1000, mas pode ser menor se a configuração do núcleo do sistema operacional não não tiver capacidade para suportar este valor (conforme determinado durante o initdb). Cada buffer possui 8192 bytes, a menos que seja escolhido um valor diferente para BLCKSZ ao construir o servidor. O valor definido deve ser pelo menos igual a 16, assim como pelo menos duas vezes o valor de max_connections; entretanto, normalmente é necessário definir um valor bem maior que o mínimo para obter um bom desempenho. São recomendados valores de alguns poucos milhares para instalações de produção. Somente pode ser definido na inicialização do servidor.

O aumento deste parâmetro pode fazer com que o PostgreSQL requisite mais memória compartilhada System V que o permitido pela configuração padrão do sistema operacional. Para obter informações sobre como ajustar estes parâmetros deve ser consultada a Seção 16.5.1, se for necessário.

Especifica a quantidade de memória utilizada pelas operações internas de classificação e tabelas de dispersão (hash tables), antes de alternar para arquivos temporários em disco. O valor é especificado em kilobytes, e o valor padrão é 1024 kilobytes (1 MB). Deve ser observado que, em uma consulta complexa, podem ser executadas várias classificações ou operações de hash em paralelo; cada uma podendo utilizar tanta memória quanto especificado por este parâmetro, antes de colocar os dados em arquivos temporários. Além disso, várias sessões em execução podem estar fazendo operações de classificação ao mesmo tempo. Portanto, a memória total utilizada pode ser várias vezes o valor de work_mem; é necessário ter este fato em mente ao escolher o valor. As operações de classificação são utilizadas por ORDER BY, DISTINCT e junções por mesclagem (merge joins). As tabelas de dispersão (hash tables) são utilizadas em junções de dispersão (hash joins), agregações baseadas em dispersão (hash-based aggregation), e no processamento baseado em dispersão (hash-based processing) de subconsultas IN.

Especifica a quantidade máxima de memória que pode ser utilizada pelas operações de manutenção, como VACUUM, CREATE INDEX e ALTER TABLE ADD FOREIGN KEY. O valor é especificado em kilobytes, e o valor padrão é 16384 kilobytes (16 MB). Uma vez que somente pode ser executada uma destas operações por vez em uma mesma sessão de banco de dados, e o servidor normalmente não possui muitas delas acontecendo ao mesmo tempo, é seguro definir este valor significativamente maior que work_mem. Definições maiores podem melhorar o desempenho do comando VACUUM e da restauração de cópias de segurança.

Especifica a profundidade máxima segura para a pilha de execução do servidor. A definição ideal deste parâmetro é o limite do tamanho da pilha imposto pelo núcleo do sistema operacional (conforme definido pelo comando ulimit -s [1] ou seu equivalente local, menos uma margem de segurança em torno de um megabyte. A margem de segurança é necessária porque a profundidade da pilha não é verificada em todas as rotinas do servidor, mas somente nas rotinas potencialmente recursivas chave, como avaliação de expressão. Definir o parâmetro acima do limite do núcleo significa que uma função recursiva fora de controle pode derrubar um processo servidor individual. A definição padrão é 2048 KB (dois megabytes), que é conservadoramente pequena e com pouca chance de risco de queda. Entretanto, pode ser muito pequena para permitir a execução de funções complexas.

16.4.3.2. Mapa do espaço livre

max_fsm_pages (integer)

Define o número máximo de páginas de disco para as quais o espaço livre será acompanhado no mapa de espaço livre compartilhado. São consumidos seis bytes de memória compartilhada para cada encaixe de página. O valor definido deve ser maior que 16 * max_fsm_relations. O valor padrão é 20000. Somente pode ser definido na inicialização do servidor.

Define o número máximo de relações (tabelas e índices) para as quais o espaço livre será acompanhado no mapa de espaço livre compartilhado. São consumidos, aproximadamente, 50 bytes de memória compartilhada por cada encaixe. O valor padrão é 1000. Somente pode ser definido na inicialização do servidor.

16.4.3.3. Utilização de recursos do núcleo

max_files_per_process (integer)

Define o número máximo permitido de arquivos abertos simultaneamente por cada subprocesso servidor. O valor padrão é 1000. Se o núcleo tiver um limite de segurança por processo, não é necessário se preocupar com esta definição. Entretanto, em algumas plataformas (notadamente a maioria dos sistemas BSD), o núcleo permite que processos individuais abram muito mais arquivos que o sistema pode suportar, quando um grande número de processos tenta abrir esta quantidade de arquivos ao mesmo tempo. Se for vista a mensagem de erro "Muitos arquivos abertos" deve-se tentar reduzir esta definição. Somente pode ser definido na inicialização do servidor.

Especifica uma ou mais bibliotecas compartilhadas a serem pré-carregadas durante a inicialização do servidor. Pode ser chamada, opcionalmente, uma função de inicialização sem parâmetros para cada biblioteca. Para especificá-la deve ser adicionado dois-pontos e o nome da função de inicialização após o nome da biblioteca. Por exemplo '$libdir/minha_bib:minha_bib_inic' faz com que minha_bib seja pré-carregada e minha_bib_inic seja executada. Para carregar mais de uma biblioteca, os nomes devem ser separados por vírgula.

Se minha_bib ou minha_bib_inic não for encontrada, a inicialização do servidor não será bem-sucedida.

As bibliotecas de linguagem procedural do PostgreSQL são pré-carregadas desta maneira, usualmente utilizando a sintaxe '$libdir/plXXX:plXXX_init', onde XXX é pgsql, perl, tcl ou python.

Fazendo a pré-carga da biblioteca compartilhada (e a inicializando, se for aplicável), ganha-se o tempo de inicialização da biblioteca quando a biblioteca é utilizada pela primeira vez. Entretanto, pode aumentar ligeiramente o tempo para inicializar cada novo processo servidor, mesmo que o processo nunca utilize a biblioteca. Portanto, este parâmetro só é recomendado para bibliotecas utilizadas pela maioria das sessões.

16.4.3.4. Retardo do VACUUM baseado no custo

Durante a execução dos comandos VACUUM e ANALYZE, o sistema mantém um contador interno que acompanha o custo estimado das várias operações de E/S que são realizadas. Quando o custo acumulado atinge um limite (especificado por vacuum_cost_limit), o processo que está realizando a operação adormece por um tempo (especificado por vacuum_cost_delay). Depois o contador é reiniciado e a execução continua.

O objetivo desta funcionalidade é permitir que os administradores reduzam o impacto na E/S gerado por estes comandos sobre as atividades de banco de dados simultâneas. Existem diversas situações onde não é muito importante que comandos como VACUUM e ANALYZE terminem rapidamente; entretanto, geralmente é muito importante que estes comandos não interfiram significativamente com a capacidade do sistema de realizar outras operações de banco de dados. O retardo do VACUUM baseado no custo fornece uma maneira dos administradores atingirem este objetivo.

Esta funcionalidade está desativada por padrão. Para ser ativada, o parâmetro vacuum_cost_delay deve ser definido com um valor diferente de zero.

vacuum_cost_delay (integer)

A quantidade de tempo, em milissegundos, que o processo adormece quando o custo limite é excedido. O valor padrão é 0, que desativa a funcionalidade de retardo do VACUUM baseado no custo. Valores positivos ativam o retardo do VACUUM baseado no custo. Deve ser observado que em muitos sistemas a resolução efetiva de adormecimento é de 10 milissegundos; definir vacuum_cost_delay com um valor que não é múltiplo de 10, pode ter o mesmo resultado que definir com o próximo múltiplo de 10 maior que o valor especificado.

O custo estimado para executar o VACUUM em um buffer encontrado no buffer cache compartilhado. Representa o custo para bloquear o buffer pool, examinar a tabela hash compartilhada, e varrer o conteúdo da página. O valor padrão é 1.

O custo estimado para executar o VACUUM em um buffer que precisa ser lido no disco. Representa o esforço para bloquear o buffer pool, examinar a tabela hash compartilhada, ler o bloco desejado no disco e varrer o seu conteúdo. O valor padrão é 10.

O custo estimado cobrado quando o VACUUM modifica um bloco que foi limpo anteriormente. Representa a E/S adicional necessária para descarregar no disco novamente um bloco que foi limpo anteriormente. O valor padrão é 20.

O custo acumulado que faz com que o processo executando o VACUUM adormeça. O valor padrão é 200.

Nota: Existem determinadas operações que prendem bloqueios críticos e que devem, portanto, terminar o mais rápido possível. O retardo do VACUUM baseado no custo não ocorre durante este tipo de operação. Portanto, é possível que o custo acumule bem acima do limite especificado. Nestes casos, para evitar retardos longos sem utilidade, o retardo real é calculado como vacuum_cost_delay * accumulated_balance / vacuum_cost_limit sendo no máximo igual a vacuum_cost_delay * 4.

16.4.3.5. Escrita em segundo plano

A partir do PostgreSQL 8.0 passa a existir um servidor em separado, chamado de escritor de segundo plano (background writer), cuja única função é escrever buffers de memória compartilhada "sujos" (dirty) no disco. O objetivo é fazer com que raramente, ou nunca, os processos servidor que tratam os comandos dos usuários tenham que aguardar uma escrita em disco, porque o escritor de segundo plano já terá feito esta escrita. Esta funcionalidade também reduz a degradação de desempenho associada aos pontos de verificação. O escritor de segundo plano escreve continuamente as páginas no disco, de modo que no momento do ponto de verificação somente é necessário escrever algumas poucas páginas, em vez de ser necessário escrever uma grande quantidade de buffers sujos como acontecia anteriormente. Entretanto, existe um aumento global na carga de E/S, porque anteriormente uma página sujada várias vezes era escrita apenas uma vez no disco no período de um ponto de verificação, enquanto agora o escritor de segundo plano pode escrever esta página no disco várias vezes no mesmo período. Na maioria das situações se prefere uma baixa carga contínua do que um pico periódico. Os parâmetros vistos nesta seção podem ser utilizados para ajustar o comportamento conforme as necessidades locais. [2]

bgwriter_delay (integer)

Especifica o retardo entre rodadas de atividade para escritor de segundo plano. A cada rodada o escritor escreve uma quantidade de buffers sujos (controlado pelos parâmetros mostrados a seguir). Os buffers selecionados são sempre os usados menos recentemente entre os buffers sujos atuais. Em seguida adormece por bgwriter_delay milissegundos e repete a operação. O valor padrão é 200. Deve ser observado que em muitos sistemas a resolução efetiva do adormecimento é de 10 milissegundos; definir bgwriter_delay com um valor que não é múltiplo de 10, pode ter o mesmo resultado que definir com o próximo múltiplo de 10 maior que o valor especificado. Somente pode ser definido na inicialização do servidor, ou no arquivo postgresql.conf .

A cada rodada não será escrito mais que esta percentagem de buffers sujos no momento (as frações são arredondadas para o próximo número inteiro de buffers acima). O valor padrão é 1. Somente pode ser definido na inicialização do servidor, ou no arquivo postgresql.conf.

A cada rodada não será escrito mais que esta quantidade de buffers sujos. O valor padrão é 100. Somente pode ser definido na inicialização do servidor, ou no arquivo postgresql.conf.

A utilização de valores menores para bgwriter_percent e bgwriter_maxpages reduz a carga extra de E/S causada pelo escritor de segundo plano, mas deixa mais trabalho a ser feito no ponto de verificação. Para reduzir o pico de carga nos pontos de verificação estes valores devem ser aumentados. Para desativar inteiramente o escritor de segundo plano os parâmetros bgwriter_percent e/ou bgwriter_maxpages devem ser definidos iguais a zero.

16.4.4. Log de escrita prévia (WAL)

Consulte também a Seção 25.2 para obter detalhes sobre o ajuste do WAL.

16.4.4.1. Definições

fsync (boolean)

Se o valor deste parâmetro for true, o servidor PostgreSQL utilizará a chamada de sistema fsync() em vários lugares para ter certeza que as atualizações estão fisicamente escritas no disco. Isto garante que o agrupamento de bancos de dados vai ser recuperado em um estado consistente após um problema de máquina ou do sistema operacional

Entretanto, a utilização de fsync() produz uma degradação de desempenho: quando a transação é efetivada, o PostgreSQL tem de aguardar o sistema operacional descarregar o log de escrita prévia no disco. Quando fsync está desativado, o sistema operacional pode desempenhar da sua melhor maneira a "buferização", ordenação e retardo na escrita. Isto pode produzir uma melhora significativa no desempenho. Porém, no caso de uma queda do sistema, podem ser perdidos, em parte ou por inteiro, os resultados das poucas últimas transações efetivadas. No pior caso, os dados podem ser danificados de uma forma irrecuperável (Para esta situação a queda do servidor de banco de dados não é um fator de risco, somente há risco dos dados ficarem danificados no caso de queda do sistema operacional).

Devido aos riscos envolvidos não existe uma definição universalmente aceita para fsync. Alguns administradores sempre desativam fsync, enquanto outros só desativam para cargas de dado pesadas, onde claramente existe um ponto de recomeço se algo de errado acontecer, enquanto outros administradores sempre deixam fsync ativado. O valor padrão para fsync é ativado, para obter o máximo de confiabilidade. Havendo confiança no sistema operacional, na máquina, e nos utilitários que acompanham (ou na bateria de reserva), pode-se levar em consideração desativar fsync.

Somente pode ser definido na inicialização do servidor, ou no arquivo postgresql.conf.

Método utilizado para obrigar a colocar as atualizações do WAL no disco. Os valores possíveis são fsync (chamada à função fsync() a cada efetivação), fdatasync (chamada à função fdatasync() a cada efetivação), open_sync (escreve os arquivos do WAL com a opção O_SYNC da função open()), e open_datasync (escreve os arquivos do WAL com a opção O_DSYNC do open()). Nem todas estas opções estão disponíveis em todas as plataformas. Somente pode ser definido na inicialização do servidor, ou no arquivo postgresql.conf.

Número de buffers de página de disco alocados na memória compartilhada para os dados do WAL. O valor padrão é 8. Esta definição somente precisa ser grande o suficiente para conter a quantidade de dados do WAL gerados por uma transação típica. Somente pode ser definido na inicialização do servidor.

Retardo entre a escrita do registro de efetivação no buffer do WAL e a descarga do buffer no disco, em microssegundos. Um retardo maior que zero permite que seja feita apenas uma chamada de sistema fsync() para várias transações efetivadas, se a carga do sistema for alta o suficiente para que outras transações fiquem prontas para efetivar dentro do intervalo especificado. Entretanto, este retardo é simplesmente desperdício se nenhuma outra transação ficar pronta para efetivar. Portanto, o retardo somente é realizado se pelo menos outras commit_siblings transações estiverem ativas no instante que o processo servidor escrever seu registro de efetivação. O valor padrão é zero (nenhum retardo).

Número mínimo de transações simultâneas abertas requerido para realizar o retardo commit_delay. Um valor maior torna mais provável que pelo menos uma outra transação fique pronta para efetivar durante o período do retardo. O valor padrão é 5.

16.4.4.2. Pontos de verificação

checkpoint_segments (integer)

Distância máxima entre pontos de verificação automático do WAL, em segmentos de arquivo de log (cada segmento possui normalmente 16 megabytes). O valor padrão é 3. Somente pode ser definido na inicialização do servidor, ou no arquivo postgresql.conf.

Tempo máximo, em segundos, entre pontos de verificação automáticos do WAL. O valor padrão é 300 segundos. Somente pode ser definido na inicialização do servidor, ou no arquivo postgresql.conf.

Escreve uma mensagem no log do servidor caso ocorra um ponto de verificação, causado pelo enchimento dos arquivos de segmento de ponto de verificação, em um tempo menor que este número de segundos. O valor padrão é 30 segundos. Zero desativa a advertência.

16.4.4.3. Cópia de segurança

archive_command (string)

O comando a ser passado para o interpretador de comandos para executar a cópia de segurança de um segmento da série de arquivos do WAL quando este é completado. Se for uma cadeia de caracteres vazia (que é o valor padrão), a cópia de segurança do WAL será desativada. Todo %p presente na cadeia de caracteres é substituído pelo caminho absoluto do arquivo cuja cópia de segurança será feita, e todo %f é substituído apenas pelo nome do arquivo. Deve ser utilizado %% para incluir o caractere % na linha de comando. Para obter mais informações deve ser consultada a Seção 22.3.1. Somente pode ser definido na inicialização do servidor, ou no arquivo postgresql.conf. file.

É importante que o comando retorne um status de saída igual a zero se, e somente se, for bem-sucedido. Exemplos:

archive_command = 'cp "%p" /mnt/server/archivedir/"%f"'
archive_command = 'copy "%p" /mnt/server/archivedir/"%f"'  # Windows

16.4.5. Planejamento de comando

16.4.5.1. Configuração do método de planejamento

Estes parâmetros de configuração fornecem um método rudimentar para influenciar os planos de comando escolhidos pelo otimizador de comandos. Se o plano padrão escolhido pelo otimizador para um determinado comando não for o ótimo, uma solução temporária pode ser obtida utilizando um destes parâmetros de configuração para forçar o otimizador a escolher um plano diferente. Entretanto, dificilmente é uma boa idéia desativar uma destas definições para sempre. Outras formas de melhorar a qualidade dos planos escolhidos pelo otimizador são o ajuste das Constantes de custo do planejador, a execução do comando ANALYZE com mais freqüência, o aumento do valor do parâmetro de configuração default_statistics_target, e o aumento da quantidade de estatísticas coletadas para colunas específicas utilizando o comando ALTER TABLE SET STATISTICS.

enable_hashagg (boolean)

Ativa ou desativa o uso pelo planejador de comandos dos planos do tipo agregação por hash. O valor padrão é ativado.

Ativa ou desativa o uso pelo planejador de comandos dos planos do tipo junção por hash. O valor padrão é ativado.

Ativa ou desativa o uso pelo planejador de comandos dos planos do tipo varredura de índice. O valor padrão é ativado.

Ativa ou desativa o uso pelo planejador de comandos dos planos do tipo junção por mesclagem. O valor padrão é ativado.

Ativa ou desativa o uso pelo planejador de comandos dos planos do tipo junção por laço aninhado. Não é possível suprimir junções por laço aninhado inteiramente, mas tornar o valor deste parâmetro igual a false desestimula a utilização deste método pelo planejador, quando há outro método disponível. O valor padrão é ativado.

Ativa ou desativa o uso pelo planejador de comandos dos planos do tipo varredura seqüencial. Não é possível suprimir as varreduras seqüenciais inteiramente, mas tornar o valor deste parâmetro igual a false desestimula a utilização deste método pelo planejador, quando há outro método disponível. O valor padrão é ativado.

Ativa ou desativa o uso pelo planejador de comandos dos passos de classificação explícita pelo planejador de comandos. Não é possível suprimir as classificações explícitas inteiramente, mas tornar o valor deste parâmetro igual a false desestimula a utilização deste método pelo planejador, quando há outro método disponível. O valor padrão é ativado.

Ativa ou desativa o uso pelo planejador de comandos dos planos do tipo varredura TID. O valor padrão é ativado.

16.4.5.2. Constantes de custo do planejador

Nota: Infelizmente, não existe nenhum método bem definido para determinar os valores ideais para a família de variáveis de "custo" mostradas abaixo. Incentivamos que sejam feitas experiências e compartilhadas as descobertas.

effective_cache_size (floating point)

Define o tamanho efetivo presumido pelo planejador acerca do cache de disco disponível para uma única varredura de índice. É um dos elementos usados na estimativa do custo de utilização de um índice; um valor maior torna mais provável a utilização de uma varredura de índice, enquanto um valor menor torna mais provável a utilização de uma varredura seqüencial. Ao definir este valor devem ser considerados os buffers de memória compartilhada do PostgreSQL, e a parcela do cache de disco do núcleo que será utilizada pelos arquivos de dado do PostgreSQL. Também deve ser levado em consideração o número esperado de comandos simultâneos que utilizam índices diferentes, uma vez que estes têm de compartilhar o espaço disponível. Este parâmetro não tem efeito sobre o tamanho da memória compartilhada alocada pelo PostgreSQL, nem reserva cache de disco do núcleo; é usado apenas para finalidades de estimativa. O valor é medido em páginas de disco, normalmente com 8192 bytes cada. O valor padrão é 1000.

Define a estimativa do planejador de comandos do custo da busca não seqüencial de uma página de disco. É medido como um múltiplo do custo da busca seqüencial de uma página. Um valor maior torna mais provável a utilização de uma varredura seqüencial, enquanto um valor menor torna mais provável a utilização de uma uma varredura de índice. O valor padrão é 4.

Define a estimativa do planejador de comandos do custo de processamento de cada linha durante o comando. É medido como uma fração do custo da busca de uma página seqüencial. O valor padrão é 0.01.

Define a estimativa do planejador de comandos do custo de processamento de cada linha de índice durante a varredura do índice. Medido como uma fração do custo da busca de uma página seqüencial. O valor padrão é 0.001.

Define a estimativa do planejador de comandos do custo de processamento de cada operador na cláusula WHERE. É medido como uma fração do custo da busca de uma página seqüencial. O valor padrão é 0.0025.

16.4.5.3. Otimização genética de comandos

geqo (boolean)

Ativa ou desativa a otimização genética de comandos, que é um algoritmo que tenta realizar um planejamento de comandos sem uma busca exaustiva. O valor padrão é ativado. A variável geqo_threshold permite uma forma mais granular para desativar GEQO para certas classes de comandos.

A otimização genética de comandos é utilizada para planejar comandos com pelo menos esta quantidade de itens envolvidos na cláusula FROM (Deve ser observado que uma construção de JOIN externa conta como apenas um item da cláusula FROM). O valor padrão é 12. Para comandos simples geralmente é melhor utilizar o planejamento determinístico exaustivo, mas para comandos com muitas tabelas o planejamento determinístico leva muito tempo.

Controla o equilíbrio entre o tempo de planejamento e a eficiência do planejamento do comando no GEQO. O valor desta variável deve ser um número inteiro no intervalo de 1 a 10. O valor padrão é 5. Valores maiores aumentam o tempo gasto para fazer o planejamento do comando, mas também aumentam a chance de ser escolhido um plano de comando eficiente.

Na verdade, a variável geqo_effort não faz nada diretamente; é utilizada apenas para calcular os valores padrão para as outras variáveis que influenciam o comportamento do GEQO (descritas abaixo). Caso se prefira, os demais parâmetros podem ser definidos manualmente.

Controla o tamanho da amostra (pool size) utilizado pelo GEQO. O tamanho da amostra é o número de indivíduos na população genética. Deve ser maior ou igual 2, e os valores úteis estão tipicamente no intervalo de 100 a 1000. Se for igual a zero (a definição padrão), então um valor padrão adequado é escolhido tomando por base geqo_effort e o número de tabelas no comando.

Controla o número de gerações utilizado pelo GEQO. As gerações especificam o número de interações do algoritmo. Deve ser maior ou igual a 1, e os valores úteis estão no mesmo intervalo do tamanho da amostra. Se for definido igual a zero (a definição padrão), então um valor padrão adequado é escolhido tomando por base geqo_pool_size.

Controla a tendência da seleção (selection bias) utilizada pelo GEQO. A tendência da seleção é a pressão seletiva dentro da população. Os valores podem estar entre 1.50 e 2.00; este último é o valor padrão.

16.4.5.4. Outras opções do planejador

default_statistics_target (integer)

Define a quantidade padrão de valores coletados nas estatísticas para as colunas das tabelas que não possuem uma quantidade específica definida através do comando ALTER TABLE SET STATISTICS. Valores maiores aumentam o tempo necessário para executar o comando ANALYZE, mas podem melhorar a qualidade das estimativas do planejador. O valor padrão é 10. Para obter informações adicionais sobre a utilização das estatísticas pelo planejador de comandos do PostgreSQL deve ser consultada a Seção 13.2.

O planejador incorpora as subconsultas nas consultas superiores se a lista FROM resultante não tiver mais do que esta quantidade de itens. Valores menores reduzem o tempo de planejamento, mas podem levar a planos de consulta inferiores. O valor padrão é 8. Geralmente é aconselhável manter este valor abaixo de geqo_threshold.

O planejador reescreve construções JOIN internas explícitas em lista de itens da cláusula FROM, sempre que resultar em uma lista com não mais do que esta quantidade de itens. Antes do PostgreSQL 7.4 as junções especificadas através da construção JOIN nunca eram reorganizadas pelo planejador. Depois o planejador foi melhorado para que as junções internas escritas desta forma pudessem ser reordenadas; este parâmetro de configuração controla até que ponto esta reordenação é realizada.

Nota: Atualmente a ordem das junções externas, especificadas através das construções JOIN, nunca é ajustada pelo planejador; portanto join_collapse_limit não tem efeito sobre este comportamento. O planejador poderá ser melhorado para reordenar algumas classes de junção externa em uma versão futura do PostgreSQL.

O padrão é definir esta variável com o mesmo valor de from_collapse_limit, o que é apropriado para a maioria dos usos. Definir o valor igual a 1 impede a reordenação dos JOINs internos. Portanto, a ordem de junção especificada no comando será a ordem real pela qual as relações serão juntadas. O otimizador de comandos nem sempre escolhe a ordem de junção ótima; os usuários avançados podem decidir definir o valor desta variável igual a 1 temporariamente e, então, especificar a ordem de junção desejada explicitamente. Uma outra conseqüência de definir o valor desta variável igual a 1 é fazer com que o planejador de comandos se comporte de forma mais parecida com o planejador de comandos do PostgreSQL 7.3, o que alguns usuários podem achar útil por motivo de compatibilidade com versões anteriores.

Definir esta variável com um valor entre 1 e from_collapse_limit pode ser útil para equilibrar o tempo de planejamento versus a qualidade de plano escolhido. (os valores maiores produzem planos melhores).

16.4.6. Relato e registro de erros

16.4.6.1. Onde registrar

log_destination (string)

O PostgreSQL dispõe de vários métodos para registrar as mensagens do servidor, incluindo stderr e syslog. No Windows também há suporte para eventlog. Este parâmetro é definido através de uma lista de destinos desejados para registrar as mensagens, separados por vírgula. O padrão é registrar apenas em stderr. Somente pode ser definido na inicialização do servidor, ou no arquivo postgresql.conf.

Permite que as mensagens enviadas para stderr sejam capturadas e redirecionadas para os arquivos de registro (log). Combinada com stderr esta opção geralmente é mais útil que registrar em syslog, uma vez que alguns tipos de mensagem podem não aparecer na saída para syslog; um exemplo comum é uma mensagem de falha do ligador dinâmico (dynamic-linker). Somente pode ser definido na inicialização do servidor.

Quando redirect_stderr está ativado, este parâmetro determina o diretório onde os arquivos de registro serão criados. Pode ser especificado como um caminho absoluto, ou como um caminho relativo ao diretório de dados do agrupamento. Somente pode ser definido na inicialização do servidor, ou no arquivo postgresql.conf.

Quando redirect_stderr está ativado, este parâmetro define os nomes dos arquivos de registro criados. O valor é tratado como um padrão para a função strftime, [3] portanto podem ser utilizados os escapes de % para especificar nomes de arquivos que variam com o tempo. Se não houver nenhum escape de % presente, o PostgreSQL anexa a época do momento de abertura do arquivo de registro ao nome do arquivo. Por exemplo, se log_filename for igual a server_log, então o nome escolhido para o arquivo será server_log.1093827753 para um registro começando em "Dom Ago 29 19:02:33 2004 MST". Somente pode ser definido na inicialização do servidor, ou no arquivo postgresql.conf.

Quando redirect_stderr está ativado, este parâmetro determina o tempo de vida máximo de um determinado arquivo de registro. Após ter decorrido esta quantidade de minutos, é criado um novo arquivo de registro. Definir o valor como zero desativa a criação de novos arquivos de registro baseado no tempo. Somente pode ser definido na inicialização do servidor, ou no arquivo postgresql.conf.

Quando redirect_stderr está ativado, este parâmetro determina o tamanho máximo de um arquivo de registro individual. Após esta quantidade de kilobytes ter sido lançada no arquivo de registro, é criado um novo arquivo de registro. Definir o valor como zero desativa a criação de novos arquivos de registro baseado no tamanho. Somente pode ser definido na inicialização do servidor, ou no arquivo postgresql.conf.

Quando redirect_stderr está ativado, este parâmetro faz com que o PostgreSQL trunque (sobrescreva), em vez de anexar, um arquivo de registro com o mesmo nome. Entretanto, o truncamento somente ocorre quando está sendo aberto um novo arquivo devido a rotação baseada no tempo, e não durante a inicialização ou rotação baseada no tamanho. Quando está desativado, os arquivos pré-existentes são anexados em todos os casos. Por exemplo, utilizar este parâmetro em combinação com um valor para log_filename, como postgresql-%H.log, resulta na geração de arquivos de registro de vinte e quatro horas, reescritos ciclicamente. Somente pode ser definido na inicialização do servidor, ou no arquivo postgresql.conf.

Exemplo: Para manter registro dos últimos 7 dias, com um arquivo de registro por dia, chamados server_log.Mon, server_log.Tue, etc., e reescrever automaticamente o registro da semana anterior com o registro da semana corrente, log_filename deve ser definido como server_log.%a, [4] log_truncate_on_rotation como true, e log_rotation_age como 1440.

Exemplo: Para manter registros de 24 horas, um arquivo de registro por hora, mas também rotacionando mais cedo se o tamanho do arquivo de registro exceder 1GB, log_filename deve ser definido como server_log.%H%M, [5] [6] log_truncate_on_rotation como true, log_rotation_age como 60, e log_rotation_size como 1000000. A inclusão de %M em log_filename faz com que toda rotação causada pelo tamanho do arquivo use um nome de arquivo diferente do nome de arquivo inicial da hora.

Quando o registro através de syslog [7] está ativado, este parâmetro determina a "facilidade" do syslog a ser utilizada. Pode ser escolhido LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7; o padrão é LOCAL0. Também deve ser consultada a documentação do processo syslog do sistema. Somente pode ser definido na inicialização do servidor.

Quando o registro via syslog está ativado, este parâmetro determina o nome de programa utilizado para identificar as mensagens do PostgreSQL nos registros do syslog. O valor padrão é postgres. Somente pode ser definido na inicialização do servidor.

16.4.6.2. Quando registrar

client_min_messages (string)

Controla que níveis de mensagem são enviadas para o cliente. Os valores válidos são DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, LOG, NOTICE, WARNING e ERROR. Cada nível inclui todos os níveis que o seguem. Quanto mais para o final estiver o nível, menos mensagens são enviadas. O valor padrão é NOTICE. Deve ser observado que aqui LOG possui uma situação relativa diferente da que tem em log_min_messages.

Controla que níveis de mensagem são escritas no log do servidor. Os valores válidos são DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, LOG, FATAL e PANIC. Cada nível inclui todos os níveis que o seguem. Quanto mais para o final estiver o nível, menos mensagens são enviadas. O valor padrão é NOTICE. Deve ser observado que aqui LOG possui uma situação relativa diferente da que tem em client_min_messages. Somente os superusuários podem aumentar esta opção.

Controla a quantidade de detalhes escritos no log do servidor para cada mensagem que é registrada. Os valores válidos são TERSE (sucinto), DEFAULT e VERBOSE, cada um adicionando mais campos às mensagens escritas. Somente os superusuários podem alterar esta definição.

Controla se o comando SQL causador da condição de erro também será registrado no log do servidor. Todas as declarações SQL causadoras de um erro do nível especificado, ou de nível mais alto, são registradas. O valor padrão é PANIC (tornando de fato esta funcionalidade desativada para o uso normal). Os valores válidos são DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, FATAL e PANIC. Por exemplo, se for definido como ERROR então todas as declarações SQL causadoras de erro, erros fatais ou pânicos serão registradas. Ativar esta opção pode ser útil para encontrar a origem de qualquer erro que apareça no log do servidor. Somente os superusuários podem alterar esta definição.

Define o tempo de execução mínimo da declaração (em milissegundos) para que a declaração seja registrada. Todas as declarações SQL cujo tempo de execução for igual ou superior ao tempo especificado serão registradas juntamente com sua duração. Definir como zero registra todos os comandos e sua duração. O valor -1 (o padrão) desativa esta funcionalidade. Por exemplo, se for definido como 250 então todas as declarações SQL com tempo de execução de 250ms ou superior serão registradas. Ativar esta opção pode ser útil para encontrar comandos não otimizados nos aplicativos. Somente os superusuários podem alterar esta definição.

Executa o servidor em silêncio. Quando o valor deste parâmetro é definido como true, o servidor executa automaticamente em segundo plano, e se desvincula do terminal controlador (o mesmo efeito da opção -S do postmaster). A saída padrão e o erro padrão do servidor são redirecionadas para /dev/null e, portanto, todas as mensagens enviadas para as mesmas são perdidas. A não ser que registrar em syslog esteja ativado, ou que redirect_stderr esteja ativado, a utilização desta opção é desencorajada, porque torna impossível ver as mensagens de erro.

Abaixo segue a relação dos vários níveis de severidade de mensagem utilizados nestas definições:

DEBUG[1-5]

Fornece informações para uso pelos desenvolvedores.

Fornece informações requisitadas implicitamente pelo usuário como, por exemplo, durante VACUUM VERBOSE.

Fornece informações que podem ser úteis para os usuários como, por exemplo, o truncamento de identificadores longos e a criação de índices como parte das chaves primárias.

Fornece advertências para o usuário como, por exemplo, COMMIT fora do bloco de transação.

Relata o erro que fez com que o comando corrente fosse interrompido.

Relata informações de interesse dos administradores como, por exemplo, atividade de ponto de verificação.

Relata o erro que fez com que a sessão corrente fosse interrompida.

Relata o erro que fez com que todas as sessões fossem interrompidas.

16.4.6.3. O que registrar

debug_print_parse (boolean)
debug_print_rewritten (boolean)
debug_print_plan (boolean)
debug_pretty_print (boolean)

Estes parâmetros ativam a emissão de várias saídas de depuração. Para cada comando executado, imprimem a árvore de análise resultante, a saída do reescritor de comando, ou o plano de execução. debug_pretty_print introduz recuos na mensagem mostrada, produzindo um formato de saída mais legível, mas muito mais longo. client_min_messages e log_min_messages devem estar em DEBUG1 ou abaixo, para ser enviada a saída para o log do cliente ou do servidor, respectivamente. Estes parâmetros estão desativados por padrão.

Gera uma linha para o log do servidor detalhando cada conexão bem-sucedida. O valor padrão é desativado embora, provavelmente, seja muito útil. Somente pode ser definido na inicialização do servidor, ou no arquivo postgresql.conf.

Gera uma linha para o log do servidor semelhante à gerada por log_connections, mas no término da sessão, incluindo a duração da sessão. Está desativado por padrão. Somente pode ser definido na inicialização do servidor, ou no arquivo postgresql.conf.

Faz com que seja registrada a duração de toda declaração completada que satisfaz log_statement. Quando esta opção é utilizada, se syslog não estiver sendo utilizado, recomenda-se que o PID ou o ID da sessão seja registrado utilizando log_line_prefix, para que seja vinculada a declaração à duração utilizando o ID do processo ou o ID da sessão. O valor padrão é desativado. Somente os superusuários podem alterar esta definição.

O valor deste parâmetro é uma cadeia de caracteres no estilo da função printf, mostrada no começo de cada linha de registro. O valor padrão é uma cadeia de caracteres vazia. Cada escape reconhecido é substituído conforme mostrado abaixo — qualquer outra coisa que se pareça com um escape é ignorada. Os demais caracteres são copiados literalmente para a linha de registro. Alguns escapes são reconhecidos apenas pelos processos de sessão, não se aplicando a processos em segundo plano como o postmaster. Syslog produz seu próprio carimbo do tempo e informação do ID do processo e, portanto, provavelmente não será desejado utilizar estes escapes quando syslog é utilizado. Somente pode ser definido na inicialização do servidor, ou no arquivo postgresql.conf.

Controla quais declarações SQL são registradas. Os valores válidos são none, ddl, mod e all. ddl registra todos os comandos de definição de dados, como CREATE, ALTER e DROP. mod registra todos as instruções de ddl, mais INSERT, UPDATE, DELETE, TRUNCATE e COPY FROM. Também são registradas as instruções PREPARE e EXPLAIN ANALYZE, se os comandos contidos nestas instruções forem do tipo apropriado.

O valor padrão é none. Somente os superusuários podem alterar esta definição.

Nota: A declaração EXECUTE não é considerada como sendo uma declaração de ddl ou mod. Quando é registrada somente é relatado o nome da declaração preparada, e não a declaração preparada inteira.

Quando uma função é definida utilizando a linguagem do lado servidor PL/pgSQL, todos os comandos executados pela função são registrados somente na primeira vez que a função é chamada por uma determinada sessão. Isto se deve ao fato da linguagem PL/pgSQL manter um cache dos planos de comando produzidos pelas declarações SQL na função.

Por padrão as mensagens de registro de conexão mostram somente o endereço de IP do hospedeiro se conectando. Ativar esta opção faz com que seja registrado o nome do hospedeiro também. Deve ser observado que, dependendo da configuração da resolução de nome de hospedeiro, pode ser imposta uma penalidade de desempenho não desprezível. Somente pode ser definido na inicialização do servidor, ou no arquivo postgresql.conf.

16.4.7. Estatísticas de tempo de execução

16.4.7.1. Monitoramento das estatísticas

log_statement_stats (boolean)
log_parser_stats (boolean)
log_planner_stats (boolean)
log_executor_stats (boolean)

Para cada comando, são registradas estatísticas de desempenho do respectivo módulo no log do servidor. É um instrumento rudimentar para traçar um perfil. log_statement_stats relata estatísticas totais da declaração, enquanto os demais relatam estatísticas por módulo. log_statement_stats não pode ser ativado junto com qualquer outro parâmetro por-módulo. Todos estes parâmetros estão desativados por padrão. Somente os superusuários podem alterar estas definições.

16.4.7.2. Coletor de estatísticas de comando e índice

stats_start_collector (boolean)

Controla se o servidor deve inicializar o subprocesso coletor de estatísticas. Está ativado por padrão, mas pode ser desativado quando se sabe que não há interesse em coletar estatísticas. Somente pode ser definido na inicialização do servidor.

Ativa a coleta de estatísticas para o comando executando no momento em cada sessão, junto com o momento em que o comando começou a executar. O valor padrão é desativado. Deve ser observado que, mesmo quando está ativado, esta informação não é visível por todos os usuários, mas somente pelos superusuários e o usuário dono da sessão sendo relatada; portanto, não deve representar um risco à segurança. Este dado pode ser acessado através da visão do sistema pg_stat_activity; para obter mais informações deve ser consultado o Capítulo 23.

Ativa a coleta de estatísticas no nível de bloco da atividade do banco de dados. O valor padrão é desativado. Se estiver ativado, os dados produzidos podem ser acessados através da família de visões do sistema pg_stat e pg_statio; para obter informações adicionais deve ser consultado o Capítulo 23.

Ativa a coleta de estatísticas no nível de linha da atividade do banco de dados. O valor padrão é desativado. Se estiver ativado, os dados produzidos podem ser acessados através da família de visões do sistema pg_stat e pg_statio; para obter informações adicionais deve ser consultado o Capítulo 23.

Se estiver ativado, as estatísticas coletadas serão zeradas sempre que o servidor for reinicializado. Se estiver desativado, as estatísticas serão acumuladas entre as reinicializações do servidor. O valor padrão é ativado. Somente pode ser definido na inicialização do servidor.

16.4.8. Padrões de conexão do cliente

16.4.8.1. Comportamento da declaração

search_path (string)

Esta variável especifica a ordem de procura nos esquemas quando um objeto (tabela, tipo de dado, função, etc.) é referenciado simplesmente por um nome, sem o componente do esquema. Quando existem objetos com nomes idênticos em esquemas diferentes, é utilizado o que for encontrado primeiro no caminho de procura. Um objeto que não está em nenhum dos esquemas do caminho de procura, somente pode ser referenciado especificando o esquema que o contém usando um nome qualificado (com ponto).

O valor de search_path deve ser uma lista de nomes de esquemas separados por vírgula. Se um dos itens da lista for o valor especial $user, então este valor é substituído pelo esquema que tem o nome retornado por SESSION_USER, caso este esquema exista (caso contrário, $user é ignorado).

É sempre feita a procura no esquema do catálogo do sistema, pg_catalog, esteja presente no caminho de procura ou não. Se estiver mencionado no caminho de procura, então a procura será feita na ordem especificada. Se pg_catalog não estiver presente no caminho de procura, então será feita a procura neste esquema antes de ser feita a procura em qualquer um dos esquemas do caminho de procura. Também deve ser observado que é feita a procura no esquema de tabela temporária, pg_temp_nnn, antes de ser feita em qualquer um dos outros esquemas.

Quando os objetos são criados sem especificar o esquema de destino, são colocados no primeiro esquema da lista do caminho de procura. Quando o caminho de procura está vazio é gerado um erro.

O valor padrão para este parâmetro é '$user, public' (onde a segunda parte é ignorada quando não há um esquema chamado public). Dá suporte ao uso compartilhado de um banco de dados (onde nenhum usuário possui um esquema privativo, e todos compartilham o esquema public), esquemas privativos por usuário, e a combinação destes. Podem ser obtidos outros resultados mudando a definição do caminho de procura padrão, tanto globalmente quanto por usuário.

O valor efetivo corrente do caminho de procura pode ser examinado através da função SQL current_schemas(). Não é exatamente o mesmo que examinar o valor de search_path, uma vez que current_schemas() mostra como as solicitações que aparecem em search_path foram resolvidas. Para obter informações adicionais sobre a função current_schemas() deve ser consultada a Tabela 9-41.

Para obter informações adicionais sobre manuseio de esquemas deve ser consultada a Seção 5.8.

Esta variável especifica o espaço de tabelas onde serão criados os objetos (tabelas e índices), quando o comando CREATE não especificar explicitamente o espaço de tabelas.

O valor pode ser o nome de um espaço de tabelas, ou uma cadeia de caracteres vazia para especificar o espaço de tabelas padrão do banco de dados corrente. Se o valor não corresponder a um espaço de tabelas existente, o PostgreSQL utiliza automaticamente o espaço de tabelas padrão do banco de dados corrente.

Para obter informações adicionais sobre espaços de tabelas deve ser consultada a Seção 18.6.

Quando é definido como false, desativa a validação da cadeia de caracteres do corpo da função durante a execução do comando CREATE FUNCTION. Normalmente definido como true. Ocasionalmente é útil desativar a validação para evitar problemas como referências à frente ao restaurar as definições das funções a partir de cópia de segurança.

Cada transação SQL possui um nível de isolamento, que pode ser "READ UNCOMMITTED", "READ COMMITTED", "REPEATABLE READ" ou "SERIALIZABLE". Este parâmetro controla o nível de isolamento padrão de cada nova transação. O valor padrão é "READ COMMITTED".

Para obter informações adicionais devem ser consultados o Capítulo 12 e SET TRANSACTION

Uma transação SQL apenas de leitura não pode alterar tabelas que não sejam temporárias. Este parâmetro controla o status de apenas para leitura padrão para cada nova transação. O valor padrão é false (leitura/escrita).

Para obter informações adicionais deve ser consultado SET TRANSACTION.

Interrompe qualquer declaração que exceda o número de milissegundos especificado. O valor zero, que é o valor padrão, desativa esta limitação.

16.4.8.2. Idioma e formatação

DateStyle (string)

Define o formato de exibição para os valores de data e hora, assim como as regras para interpretar valores de entrada de data ambíguos. Por motivos históricos esta variável contém dois componentes independentes: a especificação do formato de saída (ISO, Postgres, SQL ou German), e a especificação para entrada/saída da ordem de dia, mês e ano na data (DMY, MDY, ou YMD). Podem ser definidos separadamente ou juntos. As palavras chave Euro e European são sinônimos para DMY; as palavras chave US, NonEuro, e NonEuropean são sinônimos para MDY. Para obter informações adicionais deve ser consultada a Seção 8.5. O valor padrão é ISO, MDY.

Define a zona horária para exibir e interpretar os carimbos do tempo. O valor padrão é 'unknown', o que significa utilizar o que estiver especificado no ambiente do sistema operacional para zona horária. Para obter informações adicionais deve ser consultada a Seção 8.5.

Se estiver definido como verdade, ACST, CST, EST e SAT são interpretados como zonas horárias da Austrália, em vez de zonas horárias das Américas e Sábado. O valor padrão é falso.

Ajusta o número de dígitos mostrados em valores de ponto flutuante, incluindo float4, float8 e tipos de dado geométricos. O valor do parâmetro é adicionado ao número de dígitos padrão (FLT_DIG e DBL_DIG, conforme seja apropriado). O valor pode ser definido tão alto quanto 2, para incluir dígitos parcialmente significativos; é especialmente útil para dados de ponto flutuante em cópias de segurança, que precisem ser restaurados com exatidão. Também pode ser definido com um valor negativo para suprimir dígitos não desejados.

Define a codificação (conjunto de caracteres) do lado cliente. O padrão é utilizar a codificação do banco de dados.

Define a linguagem em que as mensagens são mostradas. Os valores aceitos são dependentes do sistema; para obter informações adicionais deve ser consultada a Seção 20.1. Se esta variável for definida como uma cadeia de caracteres vazia (que é o padrão), então o valor é herdado do ambiente de execução do servidor de uma maneira dependente do sistema.

Em alguns sistemas esta categoria de idioma não existe; definir esta variável funciona, mas não produz nenhum efeito. Existe, também, a chance de não haver mensagens traduzidas para o idioma desejado; neste caso, vão continuar sendo vistas mensagens em Inglês.

Define o idioma a ser utilizado para formatar quantias monetárias como, por exemplo, na família de funções to_char. Os valores aceitos são dependentes do sistema; para obter mais informações deve ser consultada a Seção 20.1. Se esta variável for definida como uma cadeia de caracteres vazia (que é o padrão), então o valor é herdado do ambiente de execução do servidor de uma maneira dependente do sistema.

Define o idioma a ser utilizado para formatar números como, por exemplo, na família de funções to_char(). Os valores aceitos são dependentes do sistema; para obter mais informações deve ser consultada a Seção 20.1. Se esta variável for definida como uma cadeia de caracteres vazia (que é o padrão), então o valor é herdado do ambiente de execução do servidor de uma maneira dependente do sistema.

Define o idioma a ser utilizado para formatar valores de data e hora (Atualmente esta definição não faz nada, mas poderá fazer no futuro). Os valores aceitos são dependentes do sistema; para obter mais informações deve ser consultada a Seção 20.1. Se esta variável for definida como uma cadeia de caracteres vazia (que é o padrão), então o valor é herdado do ambiente de execução do servidor de uma maneira dependente do sistema.

16.4.8.3. Outros padrões

explain_pretty_print (boolean)

Determina se EXPLAIN VERBOSE utiliza a formatação com recuos ou sem recuos para mostrar o conteúdo detalhado das árvores de comando. O valor padrão é ativado.

Se for necessário abrir um módulo carregável dinamicamente, sem que o nome de arquivo especificado no comando CREATE FUNCTION ou no comando LOAD possua componente de diretório (ou seja, o nome não contém o caractere barra), o sistema procura pelo arquivo requisitado usando este caminho.

O valor de dynamic_library_path deve ser uma lista de caminhos absolutos de diretório separados por dois-pontos. Se o elemento da lista começar pela cadeia de caracteres especial $libdir, este valor é substituído pelo diretório de biblioteca do pacote PostgreSQL compilado. Este é o local onde os módulos fornecidos na distribuição do PostgreSQL são instalados (deve ser utilizado o comando pg_config --pkglibdir para descobrir o nome deste diretório [8] ). Por exemplo:

dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'

ou, no ambiente Windows:

dynamic_library_path = 'C:\tools\postgresql;H:\my_project\lib;$libdir'

O valor padrão deste parâmetro é '$libdir'. Se o valor for definido como uma cadeia de caracteres vazia, a procura automática no caminho é desativada.

Este parâmetro pode ser modificado em tempo de execução pelos superusuários, mas a definição feita desta maneira somente é preservada até o final da conexão do cliente, portanto este método deve ser reservado para fins de desenvolvimento. A maneira recomendada para definir este parâmetro é através do arquivo de configuração postgresql.conf.

16.4.9. Gerenciamento de bloqueio

deadlock_timeout (integer)

Quantidade de tempo, em milissegundos, para aguardar pelo término do bloqueio antes de verificar a existência de uma condição de impasse (deadlock). A verificação de impasse é relativamente lenta e, portanto, o servidor não faz esta verificação toda vez que aguarda pelo término do bloqueio. Nós (otimistas?) assumimos que os bloqueios não são comuns em aplicativos em produção e, simplesmente, aguardamos pelo término do bloqueio por algum tempo antes de começar a verificar a situação de impasse. O aumento deste valor reduz a quantidade de tempo desperdiçada em verificações de impasse desnecessárias, mas atrasa o relato de erros de impasse verdadeiros. O valor padrão é 1000 (ou seja, um segundo), que provavelmente é o menor valor desejado na prática. Em servidores muito carregados pode ser desejado aumentar este valor. A definição ideal deve ser um valor superior ao tempo típico de uma transação, para melhorar a chance do bloqueio ser liberado antes de decidir verificar o impasse.

A tabela de bloqueio compartilhada é dimensionada pela hipótese de que é necessário bloquear, no máximo, max_locks_per_transaction * max_connections objetos distintos de uma vez (Desta forma, o nome deste parâmetro pode confundir: não é um limite rígido do número de bloqueios de alguma transação, mas sim o valor médio máximo). O valor padrão, 64, tem se mostrado historicamente suficiente, mas pode ser necessário aumentar este valor quando há clientes que acessam muitas tabelas diferentes em uma única transação. Somente pode ser definido na inicialização do servidor.

16.4.10. Compatibilidade de versão e de plataforma

16.4.10.1. Versões anteriores do PostgreSQL

add_missing_from (boolean)

Quando o valor for igual a true, as tabelas referenciadas por uma consulta serão automaticamente adicionadas à cláusula FROM, caso não estejam presentes. O valor padrão é true para manter a compatibilidade com as versões anteriores do PostgreSQL. Entretanto, este comportamento não é SQL-padrão, e muitas pessoas não gostam porque pode esconder enganos. Deve ser definido como false para obter o comportamento SQL-padrão de rejeitar referências a tabelas que não estão presentes na cláusula FROM.

A "variedade" (flavor) de expressão regular pode ser definida como advanced, extended ou basic. O valor padrão é advanced. Definir como extended pode ser útil para manter a compatibilidade exata com as versões do PostgreSQL anteriores a 7.4. Para obter detalhes deve ser consultada a Seção 9.7.3.1.

Controla a semântica da herança, em particular se as subtabelas são incluídas por padrão em vários comandos. Não eram incluídas nas versões anteriores a 7.1. Se for necessário usar o comportamento antigo esta variável pode ser definida como desativada, mas a longo prazo incentiva-se mudar os aplicativos para que passem a utilizar a palavra chave ONLY para excluir as subtabelas. Para obter informações adicionais sobre herança deve ser consultada a Seção 5.5.

Controla se os comandos CREATE TABLE e CREATE TABLE AS incluem a coluna OID nas tabelas criadas, caso não seja especificado WITH OIDS nem WITHOUT OIDS. Também determina se os OIDs serão incluídos nas tabelas criadas através do comando SELECT INTO. No PostgreSQL 8.0.0 o valor padrão para default_with_oids é ativado. Este também é o comportamento das versões anteriores do PostgreSQL. Entretanto, não se encoraja que seja assumido que as tabelas irão conter OIDs por padrão. Provavelmente o valor padrão desta opção será igual a desativado nas versões futuras do PostgreSQL.

Para facilitar a compatibilidade com os aplicativos que utilizam OIDs, esta opção deve ser deixada ativada. Para facilitar a compatibilidade com as versões futuras do PostgreSQL, esta opção deve ser desativada, e os aplicativos que necessitarem de OIDs para determinadas tabelas devem especificar, explicitamente, WITH OIDS no momento de criação das tabelas.

16.4.10.2. Compatibilidade de plataforma e cliente

transform_null_equals (boolean)

Quando está ativado, as expressões da forma expr = NULL (ou NULL = expr) são tratadas como expr IS NULL, ou seja, retornam verdade se expr resultar em um valor nulo, e falso caso contrário. O comportamento correto de expr = NULL é sempre retornar nulo (desconhecido). Portanto, o valor padrão desta opção é desativado.

Entretanto, no Microsoft Access formulários filtrados produzem consultas que parecem utilizar expr = NULL para testar valores nulos e, portanto, se for utilizada esta interface para acessar o banco de dados pode ser necessário ativar esta opção. Uma vez que as expressões da forma expr = NULL sempre retornam o valor nulo (utilizando a interpretação correta), não são muito úteis e, por isso, não aparecem com freqüência nos aplicativos normais, portanto esta opção produz pouco dano na prática. Porém, os novos usuários ficam freqüentemente confusos sobre a semântica das expressões que envolvem valores nulos e, portanto, esta opção não é ativada por padrão.

Deve ser observado que esta opção afeta apenas a forma exata = NULL, e não os outros operadores de comparação ou outras expressões computacionalmente equivalentes a alguma expressão envolvendo o operador de igual (como o IN). Portanto, esta opção não é uma solução geral para má programação.

Para ver informações relacionadas deve ser consultada a Seção 9.2 .

16.4.11. Opções pré-definidas

Os "parâmetros" que se seguem são apenas para leitura, sendo determinados quando o PostgreSQL é compilado, ou quando é instalado. Desta forma, foram excluídos do arquivo postgresql.conf modelo. Estes parâmetros dão informações sobre vários aspectos do comportamento do PostgreSQL que podem ser de interesse de determinados aplicativos, em particular de aplicativos cliente administrativos.

block_size (integer)

Mostra o tamanho de um bloco de disco. É determinado pelo valor de BLCKSZ quando o servidor é construído. O valor padrão é 8192 bytes. O significado de algumas variáveis de configuração (como shared_buffers) é influenciado por block_size. Para obter informações adicionais deve ser consultada a Seção 16.4.3.

Mostra se o PostgreSQL foi construído com suporte para data e hora com inteiros de 64 bits. É definido configurando com --enable-integer-datetimes quando o PostgreSQL é construído. O valor padrão é off.

Mostra o idioma usado para fazer a classificação de dados textuais. Para obter informações adicionais deve ser consultada a Seção 20.1. O valor é determinado quando o agrupamento de bancos de dados é inicializado.

Mostra o idioma que determina a classificação dos caracteres. Para obter informações adicionais deve ser consultada a Seção 20.1. O valor é determinado quando o agrupamento de bancos de dados é inicializado. Normalmente é a mesma utilizada em lc_collate, mas pode ser definido um valor diferente para aplicações especiais.

Mostra o número máximo de argumentos de uma função. É determinado pelo valor de FUNC_MAX_ARGS quando o servidor é construído. O valor padrão é 32.

Mostra o comprimento máximo do identificador. É determinado como sendo o valor de NAMEDATALEN menos 1 quando o servidor é construído. O valor padrão de NAMEDATALEN é 64; portanto o valor padrão de max_identifier_length é 63.

Mostra o número máximo de chaves de índice. É determinado pelo valor de INDEX_MAX_KEYS quando o servidor é construído. O valor padrão é 32.

Mostra a codificação do banco de dados (conjunto de caracteres). É determinado quando o banco de dados é criado. Normalmente os clientes precisam se preocupar apenas com o valor de client_encoding.

Mostra o número da versão do servidor. É determinado pelo valor de PG_VERSION quando o servidor é construído.

16.4.12. Opções personalizadas

Esta funcionalidade foi projetada para permitir que os módulos complementares (como as linguagens procedurais) adicionem opções que normalmente não são conhecidas pelo PostgreSQL. Isto permite que os módulos complementares sejam configurados da maneira padrão.

custom_variable_classes (string)

Especifica um ou vários nomes de classe a serem utilizados pelas variáveis personalizadas, na forma de uma lista separada por vírgulas. Uma variável personalizada é uma variável que normalmente não é conhecida pelo próprio PostgreSQL, mas que é utilizada por algum módulo complementar. Estas variáveis devem possuir nomes formados pelo nome da classe, um ponto, e o nome da variável. O parâmetro custom_variable_classes especifica todos os nomes de classe utilizados por uma determinada instalação. Somente pode ser definido na inicialização do servidor, ou no arquivo postgresql.conf.

A dificuldade em definir variáveis personalizadas no arquivo postgresql.conf, é que este arquivo deve ser lido antes dos módulos complementares serem carregados e, portanto, normalmente as variáveis personalizadas são rejeitadas por serem desconhecidas. Quando é definido o parâmetro custom_variable_classes, o servidor aceita definições de variáveis arbitrárias para as classes especificadas. Estas variáveis são tratadas como guardadores de lugar (placeholders), não tendo nenhuma função até que o o módulo que as define seja carregado. Quando o módulo de uma determinada classe é carregado, este adiciona as definições apropriadas de variáveis para seu nome de classe, converte os valores dos guardadores de lugar de acordo com estas definições, e emite advertências para todos os guardadores de lugar de sua classe remanescentes (que se presume como sendo variáveis de configuração escritas de forma errada).

Abaixo está mostrado um exemplo do que o arquivo postgresql.conf deve conter quando são usadas variáveis personalizadas:

custom_variable_classes = 'plr,pljava'
plr.path = '/usr/lib/R'
pljava.foo = 1
plruby.bar = true        # gera erro, nome de classe desconhecido

16.4.13. Opções do desenvolvedor

As opções a seguir foram feitas para funcionar no código fonte do PostgreSQL e, em alguns casos, ajudar na recuperação de bancos de dados seriamente danificados. Não deve haver razão para usá-las na configuração de um banco de dados de produção. Por isso, foram excluídas do arquivo postgresql.conf modelo. Deve ser observado que muitas destas opções requerem sinalizadores especiais na compilação do código fonte para que funcionem.

debug_assertions (boolean)

Ativa várias verificações de asserção. É uma ajuda de depuração. Se estiverem acontecendo problemas estranhos, ou quedas, pode se querer habilitá-la, porque podem ser mostrados erros de programação. Para utilizar esta opção a macro USE_ASSERT_CHECKING deverá estar definida quando o PostgreSQL for construído (realizado pela opção --enable-cassert do configure). Deve ser observado que debug_assertions fica ativado por padrão quando o PostgreSQL é construído com as asserções ativadas.

Número de segundos entre os relatos de lista de buffers livres. Se for maior que zero emite estatísticas buffers livres para o registro ao intervalo desta quantidade de segundos. O valor padrão igual a zero desativa o relato.

Se for diferente de zero, logo após um novo processo servidor ser lançado (forked) ocorre um retardo desta quantidade de segundos, antes de realizar o processo de autenticação. Tem por finalidade dar oportunidade de anexar o processo servidor a um depurador para acompanhar um mal comportamento na autenticação.

Gera uma grande quantidade de saída de depuração para os comandos LISTEN e NOTIFY. O valor do parâmetro client_min_messages ou log_min_messages deve ser DEBUG1, ou inferior, para que esta saída seja enviada para o log do cliente ou do servidor, respectivamente.

Várias outras opções de rastreamento e depuração de código.

Se o valor for verdade, emite saída de depuração relacionada com o WAL. Esta opção somente estará disponível se a macro WAL_DEBUG for definida quando o PostgreSQL for compilado.

A detecção de um cabeçalho de página danificado normalmente faz com que o PostgreSQL relate um erro e interrompa o comando corrente. Definir zero_damaged_pages como verdade faz com que em vez disto o sistema relate uma advertência, limpe a página danificada, e continue o processamento. Este comportamento destrói os dados, especificamente todas as linhas na página danificada, mas permite prosseguir após o erro e ler as linhas da tabela porventura presentes em páginas não danificadas. Portanto, é útil para recuperar dados se a corrupção tiver ocorrido devido à erro de máquina ou de software. Geralmente esta opção não deve ser definida como verdade, até que se tenha perdido a esperança de recuperar os dados das páginas danificadas da tabela. A definição padrão é desativado, e somente pode ser modificado por um superusuário.

16.4.14. Opções curtas

Para facilitar também estão disponíveis, para alguns parâmetros, chaves de opção de linha de comando de uma única letra, conforme descrito na Tabela 16-1.

Tabela 16-1. Chave de opção curta

$ postmaster -o '-S 1024 -s'

Qual o comando que gera um ponto de verificação manual no banco de dados no instante da execução?

O que é Checkpoint no banco de dados?

Qual o comando SQL que faz consulta no banco de dados?

O que é Checkpoint SQL Server?