Permite que sejam criados espaços de tabelas como diretórios dentro de pg_tblspc, quando é fornecida uma cadeia de caracteres de localização vazia ao comando CREATE TABLESPACE. O objetivo é permitir o teste de cenários de replicação em que os servidores primário e em-espera estão em execução na mesma máquina. Estes diretórios provavelmente vão confundir as ferramentas de cópia de segurança que esperam encontrar apenas ligações simbólicas neste local. Apenas superusuários e usuários com o privilégio SET apropriado podem alterar esta configuração.

Permite a modificação da estrutura das tabelas do sistema, bem como outras ações arriscadas nas tabelas do sistema. Caso contrário, esta ação não será permitida nem mesmo para superusuários. O uso imprudente dessa configuração pode causar perda irrecuperável dos dados, ou corromper gravemente o sistema de banco de dados. Apenas superusuários e usuários com o privilégio SET apropriado podem alterar esta configuração.

Este parâmetro contém uma lista separada por vírgulas de nomes de funções C. Se for gerado um erro, e o nome da função C interna onde o erro ocorreu corresponder a um valor da lista, será escrito um backtrace (resumo das ações) no registro de eventos do servidor, junto com a mensagem de erro. Pode ser usado para depurar áreas específicas do código-fonte.

O suporte ao backtrace não está disponível em todas as plataformas, e a qualidade dos backtraces depende das opções de compilação.

Apenas superusuários e usuários com o privilégio SET apropriado podem alterar esta configuração.

Ativar esta opção força todas as árvores de análise sintática e de planejamento serem processadas por meio da função copyObject(), para facilitar a detecção de erros e omissões nesta função. O padrão é off.

Este parâmetro só está disponível quando foi definido DEBUG_NODE_TESTS_ENABLED em tempo de compilação. (o que acontece automaticamente ao usar a opção --enable-cassert do configure).

Quando definido como 1, cada entrada de cache do catálogo do sistema é invalidada na primeira oportunidade possível, independentemente de ter realmente ocorrido algo que a tornaria inválida. Como resultado, o cache dos catálogos do sistema é inteiramente desativado, de modo que o servidor será executado de forma extremamente lenta. Os valores mais altos executam a invalidação do cache recursivamente, o que é ainda mais lento, e útil apenas para testar a própria lógica de cache. O valor padrão 0 seleciona o comportamento normal de cache do catálogo.

Este parâmetro pode ser muito útil ao tentar acionar bugs difíceis de reproduzir envolvendo alterações simultâneas no catálogo, mas raramente é necessário. Veja os arquivos de código-fonte inval.c e pg_config_manual.h para obter detalhes.

Este parâmetro tem suporte quando DISCARD_CACHES_ENABLED estava definido em tempo de compilação (o que acontece automaticamente ao usar a opção --enable-cassert do comando configure). Em construções de produção, seu valor sempre será 0, e as tentativas de o definir com outro valor vão gerar um erro.

Solicita ao kernel para minimizar os efeitos de cache para dados de relações e arquivos de WAL usando O_DIRECT (a maioria dos sistemas do tipo Unix), F_NOCACHE (macOS) ou FILE_FLAG_NO_BUFFERING (Windows).

Pode ser definido como uma cadeia de caracteres vazia (o padrão) para desativar o uso de E/S direta, ou como uma lista de operações separadas por vírgulas que devem usar E/S direta. As opções válidas são data para arquivos de dados principais, wal para arquivos de WAL e wal_init para arquivos de WAL quando são alocados inicialmente. Este parâmetro só pode ser definido na ativação do servidor.

Alguns sistemas operacionais e sistemas de arquivos não oferecem suporte para E/S direta, portanto configurações não padrão podem ser rejeitadas na ativação ou causar erros.

No momento esta funcionalidade reduz o desempenho e destina-se apenas a testes de desenvolvedores.

Permite o uso de consultas paralelas para fins de teste, mesmo em casos onde não se espera ganho de desempenho. Os valores permitidos para debug_parallel_query são off (uso do modo paralelo somente quando houver expectativa de melhoria de desempenho), on (força consulta paralela para todas as consultas em que isto for considerado seguro), e regress (como on, mas com alterações de comportamento adicionais, conforme explicado abaixo).

Mais especificamente, definir este valor como on irá adicionar um nó Gather ao topo de qualquer plano de consulta para o qual isto pareça ser seguro, de forma que a consulta seja executada em um processo paralelo. Mesmo quando um processo trabalhador paralelo não estiver disponível, ou não puder ser usado, operações como iniciar uma subtransação que seriam proibidas em um contexto de consulta paralela serão proibidas, a menos que o planejador acredite que isto irá causar a falha da consulta. Se ocorrerem falhas ou resultados inesperados quando esta opção estiver ativa, algumas funções usadas pela consulta podem precisar ser marcadas com PARALLEL UNSAFE (ou, possivelmente, PARALLEL RESTRICTED).

Definir este valor como regress tem os mesmos efeitos que defini-lo como on, além de alguns efeitos adicionais destinados a facilitar os testes de regressão automatizados. Normalmente as mensagens de um processo trabalhador paralelo incluem uma linha de contexto indicando isto, mas uma configuração de regress suprime esta linha para que a saída seja a mesma que na execução não paralela. Além disso, os nós Gather adicionados aos planos por esta configuração são ocultados na saída EXPLAIN para que a saída corresponda ao que seria obtido se esta configuração estivesse inativa.

Ativar esta opção força todas as árvores de análise sintática bruta para instruções DML serem examinadas por raw_expression_tree_walker(), para facilitar a detecção de erros e omissões nesta função. O padrão é off.

Este parâmetro só está disponível quando DEBUG_NODE_TESTS_ENABLED estava definido em tempo de compilação (o que acontece automaticamente ao usar a opção --enable-cassert do configure).

Ativar esta opção força todas as árvores de análise e planejamento serem passadas por outfuncs.c/readfuncs.c, para facilitar a detecção de erros e omissões nesses módulos. O padrão é off.

Este parâmetro só está disponível quando DEBUG_NODE_TESTS_ENABLED estava definido em tempo de compilação (o que acontece automaticamente ao usar a opção --enable-cassert do configure).

Ignora os índices do sistema ao ler as tabelas do sistema (mas ainda atualiza os índices ao modificar as tabelas). É útil ao recuperar índices de sistema danificados. Este parâmetro não pode ser alterado após o início da sessão.

Quantidade de tempo de atraso quando é iniciado um novo processo servidor, após conduzir o procedimento de autenticação. O objetivo é dar aos desenvolvedores a oportunidade de se conectar ao processo servidor com um depurador. Se o valor for especificado sem unidades, será considerado segundos. O valor zero (o padrão) desativa o atraso. Este parâmetro não pode ser alterado após o início da sessão.

Quantidade de tempo de atraso logo após a bifurcação (fork) de um novo processo servidor, antes de conduzir o procedimento de autenticação. O objetivo é dar aos desenvolvedores a oportunidade de se conectar ao processo servidor com um depurador para acompanhar mau comportamento na autenticação. Se o valor for especificado sem unidades, será considerado segundos. O valor zero (o padrão) desativa o atraso. Este parâmetro só pode ser definido no arquivo postgresql.conf, ou na linha de comando do servidor.

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

Se ativo, emite informações sobre o uso de recursos durante as operações de classificação.

Se ativo, produz informações sobre o uso de bloqueio. As informações descarregadas incluem o tipo de operação de bloqueio, o tipo de bloqueio, e o identificador exclusivo do objeto que está sendo bloqueado ou desbloqueado. Também estão incluídas máscaras de bits para os tipos de bloqueio já concedidos neste objeto, bem como para os tipos de bloqueio aguardados neste objeto. Para cada tipo de bloqueio, uma contagem do número de bloqueios concedidos e bloqueios em espera também é descarregada, bem como os totais. Um exemplo da saída do arquivo de registro de eventos é mostrado a seguir:

LOG:  LockAcquire: new: lock(0xb7acd844) id(24688,24696,0,0,0,1)
      grantMask(0) req(0,0,0,0,0,0,0)=0 grant(0,0,0,0,0,0,0)=0
      wait(0) type(AccessShareLock)
LOG:  GrantLock: lock(0xb7acd844) id(24688,24696,0,0,0,1)
      grantMask(2) req(1,0,0,0,0,0,0)=1 grant(1,0,0,0,0,0,0)=1
      wait(0) type(AccessShareLock)
LOG:  UnGrantLock: updated: lock(0xb7acd844) id(24688,24696,0,0,0,1)
      grantMask(0) req(0,0,0,0,0,0,0)=0 grant(0,0,0,0,0,0,0)=0
      wait(0) type(AccessShareLock)
LOG:  CleanUpLock: deleting: lock(0xb7acd844) id(24688,24696,0,0,0,1)
      grantMask(0) req(0,0,0,0,0,0,0)=0 grant(0,0,0,0,0,0,0)=0
      wait(0) type(INVALID)

Os detalhes da estrutura que está sendo descarregada podem ser encontrados em src/include/storage/lock.h.

Este parâmetro só estará disponível se a macro LOCK_DEBUG estava definida quando o PostgreSQL foi compilado.

Se ativo, produz informações sobre o uso de bloqueio leve. Os bloqueios leves destinam-se, principalmente, a fornecer exclusão mútua de acesso a estruturas compartilhadas de dados em memória.

Este parâmetro só estará disponível se a macro LOCK_DEBUG estava definida quando o PostgreSQL foi compilado.

Se ativo, produz informações sobre o uso de bloqueio pelo usuário. A saída é a mesma de trace_locks, apenas para bloqueios informativos.

Este parâmetro só estará disponível se a macro LOCK_DEBUG estava definida quando o PostgreSQL foi compilado.

Se ativo, não rastreia bloqueios para tabelas abaixo desse OID (usado para evitar saída em tabelas do sistema).

Este parâmetro só estará disponível se a macro LOCK_DEBUG estava definida quando o PostgreSQL foi compilado.

Rastreia incondicionalmente os bloqueios nesta tabela (OID).

Este parâmetro só estará disponível se a macro LOCK_DEBUG estava definida quando o PostgreSQL foi compilado.

Se ativo, faz a descarga das informações sobre todos os bloqueios correntes quando ocorre o tempo limite de conflito.

Este parâmetro só estará disponível se a macro LOCK_DEBUG estava definida quando o PostgreSQL foi compilado.

Se ativo, registra estatísticas sobre uso de recursos do sistema (memória e CPU) em várias operações de árvore-B.

Este parâmetro só estará disponível se a macro BTREE_BUILD_STATS estava definida quando o PostgreSQL foi compilado.

Este parâmetro deve ser usado para verificar bugs nas rotinas de reprodução do WAL. Quando ativo, são adicionadas ao registro imagens de página inteira de quaisquer buffers modificados em conjunto com o registro de WAL. Se o registro for reproduzido posteriormente, o sistema primeiro irá aplicar cada registro, e depois irá testar se os buffers modificados pelo registro correspondem às imagens armazenadas. Em certos casos (como bits de dicas), são aceitáveis pequenas variações e são ignoradas. Quaisquer diferenças inesperadas vão resultar em um erro fatal, encerrando a recuperação.

O valor padrão dessa configuração é uma cadeia de caracteres vazia, que desativa este recurso. Pode ser definido como all, para verificar todos os registros, ou como uma lista de gerenciadores de recursos separados por vírgula, para verificar apenas os registros originados por estes gerenciadores de recursos. No momento, os gerenciadores de recursos com suporte são heap, heap2, btree, hash, gin, gist, sequence, spgist, brin e generic. As extensões podem definir gerenciadores de recursos adicionais. Apenas superusuários e usuários com o privilégio SET apropriado podem alterar esta configuração.

Se ativo, produz saída de depuração relacionada ao WAL. Este parâmetro só estará disponível se a macro WAL_DEBUG estava definida quando o PostgreSQL foi compilado.

Só tem efeito quando -k/--data-checksums está ativo.

A detecção de falha na soma de verificação durante a leitura faz normalmente com que o PostgreSQL relate um erro, interrompendo a transação corrente. Definir ignore_checksum_failure como ativo faz com que o sistema ignore a falha (mas ainda relate um aviso), e continue o processamento. Este comportamento pode causar travamentos, propagar ou ocultar corrupção dos dados, ou outros problemas sérios. Entretanto, pode permitir transpor o erro e recuperar tuplas não danificadas que ainda possam estar presentes na tabela, se o cabeçalho do bloco ainda estiver correto. Se o cabeçalho estiver corrompido, será relatado um erro, mesmo se esta opção estiver ativa. O padrão é off. Apenas superusuários e usuários com o privilégio SET apropriado podem alterar esta configuração.

A detecção de um cabeçalho de página danificado normalmente faz com que o PostgreSQL relate um erro, interrompendo a transação corrente. Definir zero_damaged_pages como ativo faz com que o sistema relate um aviso, zere a página danificada na memória, e continue o processamento. Este comportamento irá destruir os dados, especificamente todas as linhas da página danificada. Entretanto, permite transpor o erro e recuperar linhas de quaisquer páginas não danificadas que possam estar presentes na tabela. Serve para recuperar dados se ocorrer corrupção devido a um erro de hardware ou de software. Geralmente não se deve ativar este parâmetro até que se tenha perdido a esperança de recuperar os dados das páginas danificadas de uma tabela. As páginas zeradas não são descarregadas para o disco; por isto, é recomendado recriar a tabela ou o índice antes de desativar este parâmetro novamente. O padrão é off. Apenas superusuários e usuários com o privilégio SET apropriado podem alterar esta configuração.

Se definido como off (o padrão), a detecção de registros do WAL com referências a páginas inválidas durante a recuperação faz com que o PostgreSQL gere um erro no nível PANIC, interrompendo a recuperação. Definir ignore_invalid_pages como on faz com que o sistema ignore referências a páginas inválidas em registros do WAL (mas ainda relate um aviso) e continue a recuperação. Este comportamento pode causar travamentos, perda de dados, propagar ou ocultar corrupção dos dados, ou outros problemas sérios. Entretanto, pode permitir que se transponha o erro no nível PANIC, conclua a recuperação, e faça com que o servidor seja carregado. Este parâmetro só pode ser definido na carga do servidor. Só tem efeito durante a recuperação, ou no modo em-espera.

Se LLVM tiver a funcionalidade necessária, registra as funções geradas no GDB. Isto torna a depuração mais fácil. O padrão é off. Apenas superusuários e usuários com o privilégio SET apropriado podem alterar esta configuração no início da sessão, e ela não pode ser alterada de forma alguma durante a sessão.

Escreve o LLVM IR gerado no sistema de arquivos, dentro do data_directory. Só é útil para trabalhar nos aspectos internos da implementação do JIT. O padrão é off. Apenas superusuários e usuários com o privilégio SET apropriado podem alterar esta configuração.

Determina se as expressões são compiladas JIT, quando a compilação JIT está ativa (veja Quando usar o JIT?). O padrão é on.

Se LLVM tiver a funcionalidade necessária, produz os dados necessários para permitir que perf crie perfis de funções geradas pelo JIT. Isto escreve arquivos em ~/.debug/jit/; o usuário é responsável por realizar a limpeza quando desejar. O padrão é off. Apenas superusuários e usuários com o privilégio SET apropriado podem alterar esta configuração no início da sessão, e ela não pode ser alterada de forma alguma durante a sessão.

Determina se a deformação da tupla é compilada JIT, quando a compilação JIT está ativa (veja Quando usar o JIT?). O padrão é on.

Quando definido como on, o padrão, o PostgreSQL irá remover automaticamente os arquivos temporários após uma falha do processo servidor. Se desativado, os arquivos serão retidos, podendo ser usados para depuração, por exemplo. Entretanto, falhas repetidas podem resultar no acúmulo de arquivos inúteis. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor.

Por padrão, após uma falha no servidor o servidor de e-mail irá interromper os processos filhos restantes enviando-lhes sinais SIGQUIT, permitindo que eles sejam encerrados de forma mais ou menos correta. Quando esta opção está definida como on, é enviado SIGABRT em seu lugar. Normalmente isto resulta na geração de um arquivo de descarga de memória (core dump) para cada um desses processos filhos. Isto pode ser útil para investigar o estado de outros processos após uma falha. Também pode consumir muito espaço em disco em caso de falhas repetidas, portanto esta opção não deve estar ativa em sistemas que não se esteja monitorando cuidadosamente. Deve-se tomar cuidado, porque não há suporte para limpeza automática dos arquivos principais. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor.

Por padrão, após tentar interromper um processo filho usando SIGQUIT, o postmaster irá aguardar por cinco segundos e, em seguida, irá enviar um SIGKILL para forçar o encerramento imediato. Quando esta opção está definida como on, é enviado SIGABRT em vez de SIGKILL. Normalmente isto resulta na geração de um arquivo de descarga de memória (core dump) para cada um desses processos filhos. Isto pode ser útil para investigar o estado de processos filhos “travados”. Também pode consumir muito espaço em disco em caso de falhas repetidas, portanto esta opção não deve estar ativa em sistemas que não se esteja monitorando cuidadosamente. Deve-se tomar cuidado, porque não há suporte para limpeza automática dos arquivos principais. Este parâmetro só pode ser definido no arquivo postgresql.conf ou na linha de comando do servidor.

Os valores permitidos são buffered e immediate. O padrão é buffered. Este parâmetro tem por finalidade testar a decodificação lógica e a replicação de grandes transações. O efeito de debug_logical_replication_streaming é diferente para o publicador e o subscritor:

Do lado do editor, debug_logical_replication_streaming permite transmitir ou serializar alterações imediatamente na decodificação lógica. Quando definida como immediate, irá transmitir cada alteração se a opção streaming de CREATE SUBSCRIPTION estiver ativa, caso contrário irá serializar cada alteração. Quando definida como buffered, A decodificação irá transmitir ou serializar as alterações quando for alcançado logical_decoding_work_mem.

Do lado do subscritor, se a opção streaming estiver definida como parallel, debug_logical_replication_streaming poderá ser usada para direcionar o processo trabalhador líder a enviar as alterações para a fila de memória compartilhada ou para serializar todas as alterações no arquivo. Quando definida como buffered, o líder irá enviar as alterações para os processos trabalhadores de aplicação em paralelo através de uma fila de memória compartilhada. Quando definida como immediate, o processo líder irá serializar todas as alterações nos arquivos e notificar os processos de aplicação paralelos para que leiam e apliquem as alterações ao final da transação.