JohnEye's questions

Tentei fazer um backup de um banco de dados do ambiente Git Bash, mas o executável não gera nada.
Se eu especificar o nome do arquivo usando o -fsinalizador, um arquivo em branco é criado, então o executável obviamente é executado, mas não faz nada - não há saída ou atividade. Usar o -vsinalizador também não o faz produzir nenhuma saída.
Se eu executar pg_dump --help, recebo saída.

Quando faço o mesmo em uma linha de comando do Windows, é solicitada uma senha e o despejo prossegue bem.

O que há de diferente no ambiente Git Bash que pg_dumpnão funciona lá? Existe alguma solução alternativa? Prefiro ficar fora da linha de comando do Windows, se possível.

Estou depurando problemas de desempenho com meu banco de dados e vejo algumas entradas incomuns no log do banco de dados:

2021-04-21 01:07:33.857 UTC [14823] user@db LOG:  duration: 933645.469 ms  plan:
Query Text: select systemv0_.id as id1_11_0_, systemv0_.createdTs as createdT2_11_0_, systemv0_.systemType as syste3_11_0_, systemv0_.foundProblemsCount as foundPro4_11_0_, systemv0_.groupid as groupid8_11_0_,... (rest omitted for brevity)

O que são esses identificadores estranhos com números e sublinhados? Normalmente, um plano de execução tem nomes e identificadores claros, como systemview.id.

Minha hipótese é que existem várias consultas simultâneas e os problemas de desempenho são devidos ao banco de dados tentando desesperadamente permanecer consistente sob condições de pouca memória. Percebi algumas coisas suspeitas em outras consultas - vários Recheck Conde Materializenós de árvore, que parecem estar acontecendo com frequência devido ao tamanho insuficiente de alguns buffers de banco de dados (causados ​​por pouca memória do host?). Seria bom se alguém pudesse confirmar ou desmascarar minha teoria.

Eu vi este erro ao tentar realizar a seguinte inserção em um PostgreSQL 8.4.20:

java.sql.BatchUpdateException: Batch entry 12 insert into perf_raw_2017_03_16 values ('3129', '182', '818', '2017-03-20 16:01:17.507000 +00:00:00', '4.9E-324') was aborted.  Call getNextException to see the cause.
org.postgresql.util.PSQLException: ERROR: "4.9E-324" is out of range for type double precision

No entanto, quando tento a mesma inserção em uma máquina diferente com o PostgreSQL 8.4.4, a inserção termina bem. Quando faço um select para verificar se o valor está lá, ele também finaliza bem:

select * from perf_raw_2017_03_20 where guid_key=3129 and property_key=182;

 guid_key | property_key | instance_id_key |       time_stamp        |         value
----------+--------------+-----------------+-------------------------+-----------------------
     3129 |          182 |             818 | 2017-03-20 16:01:17.507 | 4.94065645841247e-324

O tipo da coluna é double precision, que, segundo a documentação, é "precisão de 15 dígitos decimais". O erro faz sentido, estou realmente fora de seu alcance, então não estou muito surpreso com o erro. Aqui estão minhas perguntas embora:

O formato binário do banco de dados não muda com versões secundárias. Por que isso funcionou no 8.4.4 e não no 8.4.20?

Não encontrei nada no changelog que explicasse isso: https://bucardo.org/postgres_all_versions.html

Por que o banco de dados ainda me permite inserir o valor se eu usar um select para obtê-lo de um registro existente?

Provavelmente postarei uma resposta para essa pergunta com base no que observei, mas seria legal se alguém pudesse fornecer uma visão mais profunda desse problema.

Eu tenho um aplicativo cujo banco de dados HSQL cresce muito para alguns usuários, mas não para outros. Quando recebi um exemplo em que esse problema aconteceu, descobri que o banco de dados está quase vazio - são quase 16 GB de zeros e apenas algumas dezenas de megabytes de dados reais. Ao executar CHECKPOINT DEFRAG, ele encolhe para seu tamanho real e pequeno.

Infelizmente, não estou muito familiarizado com esse mecanismo de banco de dados e minhas pesquisas on-line produziram poucas informações úteis. Uma coisa interessante é que existe a opção de realizar a desfragmentação automaticamente ao atingir um determinado tamanho, que não usei. No entanto, eu esperaria que o banco de dados reutilizasse as linhas mortas e não as mantivesse por perto, e definitivamente não zeradas, pois isso deve ter um efeito ruim no desempenho.

Por que o banco de dados continua produzindo tanto espaço vazio, que só é interrompido por dados aqui e ali? Como posso descobrir o que está acontecendo?