Atualmente, estou executando o PostgreSQL 13, mas também observei esse comportamento no PostgreSQL 11. Estou me deparando com um problema em que um erro de violação UniqueConstraint é gerado, mas esperaria bloquear pg_advisory_xact_lockaté que a transação fosse confirmada (e visível para outras transações aguardando na fechadura) ou revertido.
Estou calculando um valor exclusivo sort_idpara linhas em uma tabela com base em uma chave estrangeira na tabela de um aplicativo da web. UniqueConstraint(sort_id, foreign_key_value). Estamos utilizando pg_advisory_xact_lockem Python via SQL Alchemy e psycopg2. Originalmente, isso foi calculado com base em um modelo SQL Alchemy (veja o sort_id mais recente na propriedade do modelo). Também tentei uma consulta direta como ( SELECT max(sort_id) from table where foreign_key_value=:value;) e ainda encontrei erros de restrição.
À medida que a simultaneidade desta chamada/funcionalidade da API aumenta, a taxa de erros de restrição aumenta. Executando thread único, nunca encontramos o erro de restrição. Isso me leva a acreditar que o bloqueio pode ser liberado antes que os dados fiquem visíveis para outras transações.
Quando é pg_advisory_xact_locklançado? Os dados ficarão visíveis para outras transações antes que o bloqueio seja realizado por um processo diferente?
Está documentado :
Não necessariamente. Por exemplo, no nível de isolamento de "leitura repetível", "a outra" transação vê os dados a partir de seu horário de início, portanto, se "a primeira" transação for confirmada após o início de "a outra", esta última poderá não ver os resultados de "a primeiro".