É possível para o mestre (5.1) ter innodb_file_per_table = 0 e para o escravo (5.1 ou 5.5) ter innodb_file_per_table = 1?
Eu tenho a seguinte consulta.
WITH d_rows AS (DELETE FROM t_a RETURNING * ) INSERT INTO t_b SELECT * FROM d_rows;
O que acontecerá se eu cancelar esta consulta (Ctrl+c no psql)? A exclusão será executada? Já está rodando? Funciona em lotes? Vejo que o t_b está crescendo enquanto a consulta está em execução. Isso é importante saber, pois se trata de muitos dados.
Eu tenho uma função de gatilho que apenas copia os valores inseridos para outra tabela. Então, todas as noites, preciso descartar e recriar esse gatilho para alguma operação de exportação.
--trigger function
CREATE OR REPLACE FUNCTION mev_copy() RETURNS trigger AS $mev_copy$
BEGIN INSERT INTO measurement_events_copy SELECT NEW.*;
RETURN NEW;
END;
O problema é que às vezes o gatilho não pode ser iniciado: o comando CREATE TRRIGGER nunca retorna e o banco de dados parece travado e coloca todas as consultas no status "PARSE esperando". Ontem foi assim por 6 horas até eu matar o gatilho de criação.
O problema se manifesta consistentemente quando a tabela measurement_events está sendo aspirada automaticamente. Ao mesmo tempo, há uma nova solicitação AccessExclusiveLock pendente para esta tabela.
Este é o gatilho de criação, nada de especial:
--CREATE TRIGGER that hangs sometimes
CREATE TRIGGER mev_copy AFTER INSERT ON measurement_events FOR EACH ROW EXECUTE PROCEDURE mev_copy();
A versão do Postgres é 8.4. Alguma ideia?