como posso sintonizar postgres para evitar esse erro?

Question

Estou recebendo o erro

ERROR: could not write block 3478284 of temporary file: No space left on device

ao executar a seguinte consulta:

INSERT INTO summary SELECT t1.a, t1.b, SUM(t1.p) AS p, COUNT(t1.*) AS c,
    t1.d, t1.r, DATE_TRUNC('month', t1.start) AS month, t2.t AS t, t2.h, t2.x
FROM raw1 t1, raw2 t2
WHERE t1.t2_id=t2.id AND (t2.t<>'a' OR t2.y) GROUP BY month, t, a, b, d, r, h, x

a tabela t1 é muito grande e a tabela t2 é muito grande

Caused by: org.postgresql.util.PSQLException: ERROR: could not write block 3478284 of temporary file: No space left on device
        at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1592)
        at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1327)
        at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:192)
        at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:451)
        at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:350)
        at org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:304)

quaisquer dicas apreciadas.

    

Answer 1

O postgres está ficando sem espaço em seu local de despejo temporário ao tentar concluir sua solicitação - A maneira de corrigir isso é executar uma consulta mais simples (que provavelmente não é útil) ou liberar mais espaço no unidade que detém PGDATA/base/pgsql_tmp/ (Se você não tiver feito um VACUUM FULL em um tempo agora pode ser um bom momento: -)

Você também pode put pgsql_tmp em sua própria partição (lembre-se das permissões, já que o Postgres tende a ficar confuso sobre essas coisas)

Note that I believe pgsql_tmp is per-tablespace these days, so if this isn't the main (base) tablespace substitute appropriately :-)

    

Answer 2

Adicione espaço no disco em que está gravando?

    

Answer 3

Eu sei que esse segmento é um pouco antigo, mas achei que isso poderia ajudar alguém, pois eu estava tendo um problema semelhante e não tinha a opção de estender o armazenamento no host remoto.

Outra maneira de resolvê-lo foi executar um script para selecionar registros em partes e percorrer os registros até que o último resultado não retorne nenhum registro. Por exemplo, algo como o abaixo deve funcionar para você.

Anote a ordem de, isso é muito importante, ou então, você pode estar selecionando registros que já foram selecionados e acabam com duplicatas (eu tive isso).

INSERT INTO resumo SELECIONAR t1.a, t1.b, soma (t1.p) AS p, COUNT (t1. *) AS c,     t1.d, t1.r, DATE_TRUNC ('mês', t1.start) AS mês, t2.t AS t, t2.h, t2.x FROM raw1 t1, raw2 t2 ONDE t1.t2_id = t2.id AND (t2.t < > 'a' OU t2.y) ordem por t1.a, t1.b limite de 100 deslocamento 0 GRUPO POR mês, t, a, b, d, r, h, x

Na execução da próxima execução, você ajusta o deslocamento para 100 e assim por diante.

Espero que ajude alguém. :)

    

Answer 4

Minha aposta é que o postgres está usando / tmp para armazenamento temporário e sua partição raiz é menor que as partições do seu sistema. Se você alterar o armazenamento temporário do postgres para um local onde tenha mais espaço, poderá corrigir isso. Ou como o post acima diz, adicione mais espaço. Para confirmar isso é escrever em / tmp olhar no arquivo de configuração ou enquanto estiver rodando a query rodando ls -lart / tmp repetidamente e se os arquivos estiverem crescendo então é aí que está escrevendo. Eu não sou um usuário do postgres, mas na maior parte você deve ser capaz de descobrir o que eu disse acima.