Felipe's questions

Os documentos dizem

Se a assinatura tiver sido configurada com run_as_owner = true, nenhuma troca de usuário ocorrerá. Em vez disso, todas as operações serão realizadas com as permissões do proprietário da assinatura. Nesse caso, o proprietário da assinatura só precisa de privilégios para SELECT, INSERT, UPDATE e DELETE da tabela de destino e não precisa de privilégios para SET ROLE para o proprietário da tabela. No entanto, isso também significa que qualquer usuário que possua uma tabela na qual a replicação esteja acontecendo pode executar código arbitrário com os privilégios do proprietário da assinatura. Por exemplo, eles poderiam fazer isso simplesmente anexando um gatilho a uma das tabelas de sua propriedade. Como geralmente é indesejável permitir que uma função assuma livremente os privilégios de outra, esta opção deve ser evitada, a menos que a segurança do usuário no banco de dados não seja motivo de preocupação.

Não tenho certeza se entendi por que isso é um risco à segurança. Não é sempre que o proprietário da tabela pode forçar a execução de código em funções que usam sua tabela? Minha intuição ingênua é que o proprietário da tabela é uma função sensível precisamente porque possui esses privilégios, enquanto a função de proprietário da assinatura pode ter privilégios muito restritivos (apenas CRUD em suas tabelas). Por que essa intuição está errada?

Estou seguindo esta resposta para adicionar uma NOT NULLrestrição a uma tabela de banco de dados existente com aproximadamente 100 milhões de linhas. No entanto, quando tento executar o processo de back-end, um arquivo ShareLock.

ALTER TABLE mytable VALIDATE CONSTRAINT myfield_not_null;

Confirmei isso verificando pg_locksem outra sessão, onde posso ver o seguinte (5447 é o pid do backend tentando VALIDATE CONSTRAINT):

mydb=> select l.pid, l.mode, l.granted, l.waitstart, a.xact_start, a.query_start, a.state from pg_locks l join pg_stat_activity a on l.pid = a.pid;
  pid  |           mode           | granted |           waitstart           |          xact_start           |          query_start          | state  
-------+--------------------------+---------+-------------------------------+-------------------------------+-------------------------------+--------
  5447 | ShareLock                | t       |                               | 2023-10-06 14:58:23.133136+00 | 2023-10-06 14:58:23.355743+00 | active 
  5447 | ShareUpdateExclusiveLock | t       |                               | 2023-10-06 14:58:23.133136+00 | 2023-10-06 14:58:23.355743+00 | active

Os documentos dizem explicitamente:

um comando VALIDATE CONSTRAINT pode ser emitido para verificar se as linhas existentes satisfazem a restrição. A etapa de validação não precisa bloquear atualizações simultâneas, pois sabe que outras transações imporão a restrição às linhas que inserem ou atualizam; apenas as linhas pré-existentes precisam ser verificadas. Portanto, a validação adquire apenas um bloqueio SHARE UPDATE EXCLUSIVE na tabela que está sendo alterada.

O ShareLock está bloqueando algumas consultas que precisam de RowExclusiveLock (atualizar/inserir/excluir).

Como posso validar a restrição sem usar um ShareLock?

Como descobri ao pesquisar esta questão , converter uma coluna de varchar(100)[]para text[]requer uma reescrita de tabela e reconstrução de índices.

Existe uma maneira de gerenciar essa conversão sem o bloqueio e reescrita por meio de alguns truques de catálogo como o usado nesta pergunta ? Particularmente interessado na versão 10, se possível