Início / dba / Perguntas / 84739
Accepted
John Powell
Asked: 2014-12-10 12:37:34 +0800 CST

Altere a instrução da tabela em espera (por horas, na máquina de desenvolvimento), mas nenhum bloqueio é exibido

  • 772

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.

postgresql locking

2 respostas

  1. Best Answer

    De acordo com as notas fornecidas no wiki para essa consulta, ele mostra apenas bloqueios de nível de linha .

    ALTER TABLEACCESS EXCLUSIVEleva um bloqueio de nível de tabela . Uma ou mais transações manterão bloqueios mais fracos na tabela que impedem ALTER TABLEa aquisição de seu bloqueio.

    Você pode identificar o bloqueio sendo aguardado com algo como:

    select * 
from pg_stat_activity sa 
inner join pg_locks lwait on (sa.pid = lwait.pid) 
where sa.waiting = 't' 
  and sa.query like '%ALTER%' 
  and not lwait.granted;

    (altere "sa.pid" para "sa.procpid" na versão 9.1 e anteriores).

    • 4

  2. O problema acabou sendo um processo shp2pgsql que foi executado em um loop em um script de shell na tela que foi concluído com êxito várias horas antes de eu postar esta pergunta. Ele não apareceu em pg_locks, nem em pg_stat_activity, pois é um processo separado, que estava sendo canalizado para o psql. Matar esta janela dentro da tela permitiu que a ALTER TABLEinstrução fosse executada. A declaração em questão era mais ou menos assim:

    for x in $(ls *.shp); do shp2pgsql $x schema_name.table_name | psql db_name; done

    Isso é algo que executei literalmente centenas de vezes e nunca vi esse comportamento antes, então ainda não sei por que, mas pelo menos está resolvido.

    • 0

relate perguntas