Como posso solicitar uma liberação dos logs de transações do postgresql?

Eu tenho o seguinte problema: uma distribuição Linux "vertical" (Sophos UMT) vem com o PostgreSQL 9.2 para armazenar sua configuração. Infelizmente, desde a última atualização, parece que os logs de transações (WAL) de algumas instâncias estão crescendo sem nunca serem liberados. Isso faz com que a pasta pg_xlog cresça várias vezes maior que a pasta base.

Agora estou em uma situação delicada: devido ao crescimento excessivo dos arquivos WAL, o disco de uma dessas máquinas (uma VM) ficará cheio antes de segunda-feira. Já abri um caso de suporte com o fornecedor, mas, até o momento, eles não estão sendo muito úteis (sugerem que reconstruamos a VM com discos maiores).

O backup desse banco de dados nunca é feito porque o software está executando backups de uma maneira diferente (ele possui seu próprio procedimento de backup e envia arquivos de backup por email) e suponho que essa seja a razão pela qual os WAFs estão crescendo tanto.

Receio estar longe de ser um especialista em PostgreSQL, por isso é muito provável que eu esteja fazendo uma pergunta boba ou óbvia, mas qual é o procedimento para solicitar a liberação dos arquivos WAL?

Idealmente, estou procurando um procedimento que permita liberar esses arquivos WAL no sistema problemático para ganhar tempo suficiente para que o fornecedor emita uma correção melhor.

Edit : Conforme solicitado, aqui está a saída da SELECT version();consulta:

 PostgreSQL 9.2.4 on i686-pc-linux-gnu, compiled by gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973], 32-bit

(1 linha)

E a SELECT name, current_setting(name), source FROM pg_settings WHERE source NOT IN ('default', 'override');consulta

 hot_standby                      | on                  | configuration file
 listen_addresses                 | *                   | configuration file
 log_destination                  | syslog              | configuration file
 log_min_duration_statement       | -1                  | configuration file
 log_min_error_statement          | error               | configuration file
 log_min_messages                 | notice              | configuration file
 maintenance_work_mem             | 512MB               | configuration file
 max_connections                  | 300                 | configuration file
 max_files_per_process            | 1000                | configuration file
 max_prepared_transactions        | 0                   | configuration file
 max_stack_depth                  | 2MB                 | configuration file
 max_standby_streaming_delay      | 10s                 | configuration file
 max_wal_senders                  | 10                  | configuration file
 password_encryption              | on                  | configuration file
 pg_stat_statements.max           | 1000                | configuration file
 pg_stat_statements.save          | on                  | configuration file
 pg_stat_statements.track         | all                 | configuration file
 pg_stat_statements.track_utility | off                 | configuration file
 port                             | 5432                | configuration file
 random_page_cost                 | 2                   | configuration file
 replication_timeout              | 1min                | configuration file
 seq_page_cost                    | 1                   | configuration file
 shared_buffers                   | 512MB               | configuration file
 shared_preload_libraries         | pg_stat_statements  | configuration file
 ssl                              | off                 | configuration file
 stats_temp_directory             | pg_stat_tmp         | configuration file
 superuser_reserved_connections   | 20                  | configuration file
 synchronous_commit               | local               | configuration file
 syslog_facility                  | local0              | configuration file
 syslog_ident                     | postgres            | configuration file
 temp_buffers                     | 256MB               | configuration file
 temp_file_limit                  | -1                  | configuration file
 TimeZone                         | GMT                 | configuration file
 timezone_abbreviations           | AlmostAll           | configuration file
 track_activities                 | on                  | configuration file
 track_activity_query_size        | 4096                | configuration file
 track_counts                     | on                  | configuration file
 track_functions                  | none                | configuration file
 track_io_timing                  | on                  | configuration file
 unix_socket_directory            | /var/run/postgresql | configuration file
 unix_socket_group                | postgres            | configuration file
 unix_socket_permissions          | 0777                | configuration file
 update_process_title             | on                  | configuration file
 vacuum_defer_cleanup_age         | 0                   | configuration file
 wal_buffers                      | 16MB                | configuration file
 wal_keep_segments                | 100                 | configuration file
 wal_level                        | hot_standby         | configuration file
 wal_receiver_status_interval     | 5s                  | configuration file
 work_mem                         | 512MB               | configuration file
(69 rows)

Edit2

Finalmente reinstalamos o servidor inteiro (conforme solicitado pelo suporte da Sophos), mas usando a versão anterior e um disco maior. Aparentemente, a versão mais antiga está usando muito menos espaço para o WAL do que a nova.

Por curiosidade, executei a verificação dos parâmetros pgsql da versão e do 7non-default e obtive resultados bem diferentes:

PostgreSQL 8.4.14 on i686-pc-linux-gnu, compiled by GCC gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973], 32-bit

e

              name               | current_setting |        source
---------------------------------+-----------------+----------------------
 autovacuum_analyze_scale_factor | 0.0005          | configuration file
 checkpoint_segments             | 12              | configuration file
 checkpoint_warning              | 0               | configuration file
 escape_string_warning           | off             | configuration file
 fsync                           | on              | configuration file
 listen_addresses                | *               | configuration file
 log_destination                 | syslog          | configuration file
 log_timezone                    | Europe/Zurich   | command line
 maintenance_work_mem            | 1GB             | configuration file
 max_connections                 | 300             | configuration file
 max_stack_depth                 | 2MB             | environment variable
 port                            | 5432            | configuration file
 shared_buffers                  | 32MB            | configuration file
 standard_conforming_strings     | off             | configuration file
 syslog_facility                 | local0          | configuration file
 syslog_ident                    | postgres        | configuration file
 temp_buffers                    | 1024            | configuration file
 TimeZone                        | UTC             | configuration file
 timezone_abbreviations          | AlmostAll       | configuration file
 work_mem                        | 512MB           | configuration file
(20 rows)

Parece-me que houve muitas mudanças entre essas duas versões.

Muito provavelmente o que você vê é um checkpoint_segmentsvalor enorme e longo checkpoint_timeout; alternativamente, eles podem ter definido wal_keep_segmentsum valor muito grande se ele oferecer suporte à replicação de streaming.

Você pode forçar um ponto de verificação com o CHECKPOINTcomando Isso pode interromper o banco de dados por algum tempo se ele acumulou uma quantidade enorme de WAL e não o tiver escrito em segundo plano. Se checkpoint_completion_targetfor baixo (menor que 0,8 ou 0,9), é provável que haja um grande atraso de trabalho a ser feito no momento do ponto de verificação. Esteja preparado para que o banco de dados fique lento e sem resposta durante o ponto de verificação. Você não pode abortar um ponto de verificação, uma vez que ele começa normalmente; você pode travar o banco de dados e reiniciá-lo, mas isso apenas o coloca de volta para onde estava.

Não tenho certeza, mas tenho a sensação de que um ponto de verificação também pode resultar no crescimento do banco de dados principal - e faça isso antes que qualquer espaço seja liberado no WAL, se houver. Portanto, um ponto de verificação pode fazer com que você fique sem espaço, algo que é muito difícil de recuperar sem adicionar mais armazenamento pelo menos temporariamente.

Agora seria um bom momento para obter um backup adequado do banco de dados - use pg_dump -Fc dbnamepara despejar cada banco de dados e pg_dumpall --globals-onlydespejar definições de usuário etc.

Se você pode pagar o tempo de inatividade, parar o banco de dados e levar uma cópia do nível do sistema de arquivos de todo o diretório de dados (a pasta que contém pg_xlog, pg_clog, global,base , etc). Não faça isso enquanto o servidor estiver em execução e não omita nenhum arquivo ou pasta, eles são todos importantes (bem, exceto pg_log, mas é uma boa idéia manter os registros de texto de qualquer maneira).

Se você quiser um comentário mais específico sobre a causa provável (e, portanto, posso ter mais certeza da minha hipótese), execute as seguintes consultas e cole a saída delas na sua resposta (em um bloco recuado por código) e comente para que eu sou notificado:

SELECT version();

SELECT name, current_setting(name), source
  FROM pg_settings
  WHERE source NOT IN ('default', 'override');

É possível que a configuração checkpoint_completion_target = 1e a parada e a reinicialização do banco de dados possam fazer com que ele comece a gravar agressivamente o WAL enfileirado. Ele não liberará nenhum até que faça um ponto de verificação, mas você pode forçar uma vez que a atividade de gravação diminua (conforme medido com sar, iostat, etc.). Não testei para ver se checkpoint_completion_targetafeta o WAL já gravado quando alterado em uma reinicialização; considere testar isso em um teste descartável PostgreSQL você initdbem outra máquina primeiro.

Os backups não têm nada a ver com retenção e crescimento do WAL; não está relacionado ao backup.

Vejo:

• O manual do PostgreSQL no WAL
• O manual do PostgreSQL sobre configuração do WAL
• depesz em checkpoint_completion_target
• depesz no WAL