Início / dba / Perguntas / 141604
Accepted
chx
Asked: 2016-06-19 04:18:04 +0800 CST

Como CREATE OR REPLACE pode falhar com já existe?

  • 772

DETAIL: Key (proname, proargtypes, pronamespace)=(rand, , 2200) already exists.: CREATE OR REPLACE FUNCTION "rand"() RETURNS float AS

Como diabos isso é possível? Como pode CREATE OR REPLACEfalhar com já existe? Isso está em um contêiner docker, ambiente completamente intocado e é o único que o código é executado. Sim, pode ser executado repetidamente, mas é por isso que OR REPLACEestá lá. Eu não entendi. Aqui está o comando completo:

  if (!$connection->query("SELECT COUNT(*) FROM pg_proc WHERE proname = 'rand'")->fetchField()) {
    $connection->query('CREATE OR REPLACE FUNCTION "rand"() RETURNS float AS
      \'SELECT random();\'
      LANGUAGE \'sql\'');
  }
postgresql concurrency

1 respostas

  1. Best Answer

    A OR REPLACEcláusula in CREATE FUNCTIONnão se destina à execução paralela contínua, mas sim para evitar a eliminação da função quando queremos apenas atualizar o corpo. Do documento :

    Se você descartar e recriar uma função, a nova função não será a mesma entidade que a antiga; você terá que descartar as regras, exibições, gatilhos etc. existentes que se referem à função antiga. Use CREATE OR REPLACE FUNCTION para alterar uma definição de função sem quebrar os objetos que se referem à função.

    Agora, se várias sessões emitirem o mesmo CREATE OR REPLACE FUNCTIONem paralelo, há de fato uma condição de corrida potencial que é tratada com base no índice exclusivo em (proname, proargtypes, pronamespace), e retorna ao chamador como um erro.

    O erro mencionado na pergunta acontece se, por exemplo:

    • a sessão #1 inicia CREATE OR REPLACEe descobre que a função não existe, então ela a cria, inserindo pg_proce bloqueando a (proname, proargtypes, pronamespace)entrada correspondente no índice.

    • a sessão #2 inicia CREATE OR REPLACE, descobre que a função não existe (porque #1 ainda não foi confirmada) e é colocada para aguardar o bloqueio do índice.

    • a sessão nº 1 é confirmada.

    • a sessão #2 tenta inserir e falha.

    Observe que não usar BEGIN/COMMIT explícito não altera a condição de corrida: os pares BEGIN/COMMIT são apenas implícitos em cada instrução SQL.

    Para que essa sequência paralela funcione perfeitamente, OR REPLACEprecisaria estar para CREATE FUNCTIONo que ON CONFLICTestá para INSERT, mas não é o caso.

    Para lidar com DDL conflitantes ou idênticos que podem ser executados em paralelo, provavelmente você deve usar um bloqueio explícito no início da sequência para colocá-lo como um todo em uma seção crítica. Bloqueios consultivos podem ser usados ​​para isso. Ou você precisa implementar uma estratégia de "repetir em caso de falha" com pontos de salvamento em torno de declarações individuais.

    • 3

relate perguntas