Início / dba / Perguntas / 280284
Accepted
John Bachir
Asked: 2020-11-25 14:56:20 +0800 CST

Que tipo de bloqueios são necessários ao criar um índice Postgres simultaneamente?

  • 772

Eu sei que quando um índice está sendo criado simultaneamente, apenas um bloqueio SHARE ShareUpdateExclusiveLock é necessário.

Mas existe um tipo mais rigoroso de bloqueio necessário no início do processo por um pequeno período de tempo? Ou é necessário apenas um bloqueio SHARE ShareUpdateExclusiveLock para toda a operação?

Estou perguntando porque estou querendo saber quais tipos de tempos limite são vantajosos para definir ao criar um índice simultaneamente.

postgresql index

1 respostas

  1. Best Answer

    Bem, quando a documentação não é suficiente é possível olhar diretamente no código. Darei links para já lançados PostgreSQL 13.1( REL_13_1tag) para evitar possíveis alterações de número de linha no futuro.

    Provavelmente não descreverei todo o caminho do código do comando do cliente. Pela gramática, sabemos que precisamos IndexStmtdo nó de comando - a mesma gramática para o índice de criação simultânea e não concorrente. Tudo o que for útil começará emProcessUtilitySlow

    E aqui, no comentário de case T_IndexStmt, pode ser encontrada a resposta direta para a pergunta:

    /*
 * .... To avoid lock upgrade hazards, it's
 * important that we take the strongest lock that will
 * eventually be needed here, so the lockmode calculation
 * needs to match what DefineIndex() does.
 */
lockmode = stmt->concurrent ? ShareUpdateExclusiveLock
    : ShareLock;

    Em geral, o PostgreSQL não atualizará o bloqueio durante a execução do comando. E levará o bloqueio mais forte que eventualmente será necessário. Pois CREATE INDEX CONCURRENTLYé ShareUpdateExclusiveLock. Não é um SHAREbloqueio como mencionado em questão.

    Mas vamos continuar lendo:

    • no caso de tabela particionada find_all_inheritorsadquirirá o mesmo lockmode nos herdeiros.
    • em transformIndexStmtpodem ser encontrados alguns modos de bloqueio, mas NoLocke AccessShareLock- eles são mais fracos do queShareUpdateExclusiveLock
    • em DefineIndexvemos outro lembrete:
         * To avoid lock upgrade hazards, that lock should be at least
     * as strong as the one we take here.

    E decida usar novamente o ShareUpdateExclusiveLock para compilar simultaneamente. Esta parte do código é visivelmente longa (ainda não tão grande quanto, por exemplo, planner), mas legível.

    estou faltando alguma coisa? Provavelmente. Então vamos construir o PostgreSQL com -DLOCK_DEBUGa opção de depurar o comportamento de bloqueio e ver isso acontecer:

    ./configure  --prefix=/home/melkij/tmp/pgdev/inst --enable-cassert --enable-debug CFLAGS="-ggdb -Og -g3 -fno-omit-frame-pointer -DLOCK_DEBUG" --enable-tap-tests
make -sj 4
make install
initdb ...
pg_ctl start ...
# then psql with follow commands
create table foo as select generate_series(1,1000) as id;
set trace_locks = true;
create index concurrently on foo (id);
select oid, relname, relkind from pg_class where oid in (16387,16393);
#  oid  |  relname   | relkind 
#-------+------------+---------
# 16387 | foo        | r
# 16393 | foo_id_idx | i

    trace_locksregistrará muitas coisas, mas estamos interessados ​​em:

    [vxid:3/62 txid:0] [CREATE INDEX] LOG:  LockAcquire: lock [12664,16387] ShareUpdateExclusiveLock
[vxid:3/62 txid:0] [CREATE INDEX] LOG:  LockAcquire: lock [12664,16387] ShareUpdateExclusiveLock
[vxid:3/62 txid:0] [CREATE INDEX] LOG:  LockAcquire: lock [12664,16393] AccessExclusiveLock
[vxid:3/62 txid:495] [CREATE INDEX] LOG:  LockAcquire: lock [12664,16387] ShareUpdateExclusiveLock
[vxid:3/63 txid:0] [CREATE INDEX] LOG:  LockAcquire: lock [12664,16387] ShareUpdateExclusiveLock
[vxid:3/63 txid:0] [CREATE INDEX] LOG:  LockAcquire: lock [12664,16393] RowExclusiveLock
[vxid:3/64 txid:0] [CREATE INDEX] LOG:  LockAcquire: lock [12664,16387] ShareUpdateExclusiveLock
[vxid:3/64 txid:0] [CREATE INDEX] LOG:  LockAcquire: lock [12664,16393] RowExclusiveLock
[vxid:3/64 txid:0] [CREATE INDEX] LOG:  LockAcquire: lock [12664,16393] ExclusiveLock
[vxid:3/64 txid:0] [CREATE INDEX] LOG:  LockAcquire: lock [12664,16393] ExclusiveLock

    lock [12664,16387]aqui significa database OID = 12664, pg_class OID = 16387(essas linhas são registradas em LockAcquireExtended).

    Então, na verdade, adquirimos apenas ShareUpdateExclusiveLockna própria mesa. OID=16393com vários outros bloqueios é o índice que este comando construiu. Embora níveis de bloqueio pesados ​​sejam mencionados para esse objeto, ele não interferirá em outras consultas. Create index concurrentlyO comando foi especialmente projetado para funcionar com segurança durante a execução de consultas normais de aplicativos.

    • 6

relate perguntas