John Powell's questions

Estou tentando despejar algumas tabelas de um servidor 9.5 beta 2 para um servidor 9.4.4. A forma do comando que estou usando é bastante padrão:

pg_dump -t table dbname | psql -h hostname -d dbname

Estou usando o usuário Postgres, que provavelmente não é o ideal, mas como são duas caixas de processamento de dados de desenvolvimento que só eu uso e é relevante para o erro que se segue. Inicialmente, recebi o erro

ERRO: parâmetro de configuração não reconhecido "row_security"

o que é esperado, pois esse recurso é novo no 9.5 e, sim, percebo que não é aconselhável pg_dump entre diferentes versões do Postgres, mas, infelizmente inevitável, visto que encontrei um bug muito obscuro e preciso mover um grande quantidade de dados estáticos uma vez.

Portanto, usando este hack hediondo para remover o erro row_security e ativando a parada no primeiro erro:

pg_dump -t tablemame dbname |sed 's/SET row_security = off;//'|
psql -v ON_ERROR_STOP=1 -h hostname -d dbname

Eu agora recebo:

ERRO: permissão negada para criar "pg_catalog.tablename" DETALHE: as modificações do catálogo do sistema não são permitidas no momento

Embora possa ser indesejável usar o usuário/função do Postgres, entendo que não deve haver problemas de permissão dessa natureza. Estou aberto a qualquer sugestão, tendo em mente que esta é uma operação única e que são caixas de desenvolvimento de processamento de dados não conectadas a nenhum serviço ao vivo, portanto, a conveniência é preferida às políticas ideais de acesso a dados corporativos. Dito isto, seria bom entender como fazer isso corretamente e evitar isso no futuro.

Eu tenho tentado emitir um simples:

ALTER TABLE tablename ADD COLUMN id_col character varying (30)

type em uma compilação do Postgres 9.1.13 no Debian. O aplicativo ainda está em beta privado, então o volume é baixo, mas algo está bloqueando essa afirmação. Seguindo esta postagem de monitoramento de bloqueio do Postgres e executando a consulta,

SELECT bl.pid        AS blocked_pid,
     a.usename       AS blocked_user,
     kl.pid          AS blocking_pid,
     ka.usename      AS blocking_user,
     a.current_query AS blocked_statement
 FROM  pg_catalog.pg_locks  bl
 JOIN pg_catalog.pg_stat_activity a  ON a.procpid = bl.pid
 JOIN pg_catalog.pg_locks    kl ON kl.transactionid = bl.transactionid AND kl.pid != bl.pid
 JOIN pg_catalog.pg_stat_activity ka ON ka.procpid = kl.pid
 WHERE NOT bl.granted;

não retorna nenhum resultado.

Se eu correr,

SELECT * FROM pg_stat_activity

tudo o que vejo é a ALTER TABLEdeclaração com waiting = te algumas outras consultas em um estado IDLE.

Eu não sou um DBA, mais um desenvolvedor de banco de dados, então peço desculpas se estou perdendo algo realmente óbvio, mas nunca vi uma situação como esta em uma caixa de desenvolvimento de baixo volume, então não sei como proceder.

Temos um banco de dados com pouco mais de 200 gb de tamanho, com cerca de 430 milhões de linhas, uma chave primária e um índice espacial. A cada poucas semanas, recebemos uma atualização que envolve cerca de 3 milhões de linhas, excluindo alguns recursos antigos e atualizando novos. Isso é feito off-line. Também temos uma tabela de histórico, que armazena as exclusões acumuladas de cada atualização. Esta tabela está atualmente em torno de 20 gb e 40 tem milhões de linhas. Essencialmente, primeiro inserimos na tabela de histórico qualquer coisa que esteja marcada como deletar na tabela de alteração, então excluímos tudo da tabela principal, seja para deletar ou novo, e então inserimos na nova tabela todos os registros alterados (todos off-line, para ser claro).

Se eu executar isso em um único procedimento/função, uma reescrita de tabela parece ser acionada, pois voltei depois de algumas horas e descobri que falhou devido ao uso do espaço em disco disponível, cerca de 100 gb. Se eu executá-lo linha por linha em um console psql, não haverá esse problema. Como não há instruções DDL e o número total de linhas alteradas é muito menor do que o tamanho total do banco de dados, estou confuso sobre o que pode estar causando essa quantidade de uso de disco temporário, pois o espaço total necessário para registrar toda a alteração como um transação parece ser muito menor.

Existe alguma regra prática para isso ou uma consulta de diagnóstico simples que posso executar para ver o que está acontecendo?