Determinando qual nível de isolamento é apropriado

A questão parece um quebra-cabeça que parece muito simples, mas talvez não tão simples, ou apenas finge ser complexo... Vou tentar o meu melhor para respondê-la como eu a entendo. Peço desculpas se entendi mal algumas dicas óbvias.

Com o PostgreSQL, não há real Read uncommitted- você obtém arquivos Read committed. Citando a documentação :

No PostgreSQL, você pode solicitar qualquer um dos quatro níveis de isolamento de transação padrão, mas internamente apenas três níveis de isolamento distintos são implementados, ou seja, o Read Uncommittedmodo do PostgreSQL se comporta como Read Committed. Isso ocorre porque é a única maneira sensata de mapear os níveis de isolamento padrão para a arquitetura de controle de simultaneidade multiversão do PostgreSQL.

A questão não parece muito clara para mim porque os níveis de isolamento são importantes quando você tem consultas simultâneas e nenhuma outra consulta mencionada, então não me culpe muito se eu perder alguma coisa.

Se colocarmos os níveis de isolamento restantes na ordem "Leitura confirmada"->"Leitura repetível"->"Serializável", a sobrecarga aumentará de acordo. Portanto, precisamos verificá-los na mesma ordem e, uma vez satisfeitos, não há necessidade de verificar os níveis restantes (eles estarão bem, mas com mais sobrecarga). Tanto quanto eu entendo, UPDATE Courses set dept = 'New department' coursed_id = ’CPSC1350’faz o trabalho necessário. Na documentação do Postgre que descreve o nível de isolamento confirmado de leitura,

Os comandos UPDATE, DELETE, SELECT FOR UPDATE e SELECT FOR SHARE se comportam da mesma forma que SELECT em termos de pesquisa de linhas de destino: eles encontrarão apenas linhas de destino que foram confirmadas no horário de início do comando. No entanto, essa linha de destino pode já ter sido atualizada (ou excluída ou bloqueada) por outra transação simultânea no momento em que é encontrada. Nesse caso, o aspirante a atualizador aguardará a confirmação ou reversão da primeira transação de atualização (se ainda estiver em andamento). Se o primeiro atualizador reverter, seus efeitos serão negados e o segundo atualizador poderá prosseguir com a atualização da linha originalmente encontrada. Se o primeiro atualizador confirmar, o segundo atualizador irá ignorar a linha se o primeiro atualizador a excluiu, caso contrário, ele tentará aplicar sua operação à versão atualizada da linha. A condição de pesquisa do comando (a cláusula WHERE) é reavaliada para ver se a versão atualizada da linha ainda corresponde à condição de pesquisa. Nesse caso, o segundo atualizador prossegue com sua operação usando a versão atualizada da linha.

Eu diria que estou satisfeito com tal comportamento neste caso, então irei, a READ COMMITTEDmenos que haja outras restrições não mencionadas na pergunta.