Estou fazendo este curso essencial do EDB PostgreSQL e o instrutor explicou sobre a arquitetura PostgreSQL referindo-se ao diagrama que, sempre que um cliente faz uma solicitação de atualização e supõe que os dados estão presentes no buffer compartilhado (isso significa que não há necessidade de buscá-los no armazenamento de arquivos), então ' farei uma entrada nos buffers WAL e, ao confirmar , o gravador WAL gravará a transação nos logs de transações e a tornará permanente, mas não nos sistemas de arquivos (até onde entendi, essa é a tarefa do checkpointer , abaixo). tão bom.
imagem cortesia traning.enterprisedb.com
Agora vem o checkpointer, é um processo que é executado após cada determinado intervalo de tempo "geralmente 5 minutos é o tempo ideal" e grava qualquer coisa no buffer compartilhado no armazenamento de arquivos.
Minha pergunta é: suponha que o checkpointer tenha sido executado e depois disso eu iniciei uma transação atômica e transferi 100 dólares para meu amigo, como é que meu amigo pode vê-lo imediatamente, o Postgres está fazendo consulta aos logs de transações? Ou como isso está acontecendo?
Mas depois de pensar um pouco, percebo que quando é feita a solicitação para atualizar os dados e para atualizá-los, o Postgres os traz para a memória principal e uma maneira viável de fazer isso é acompanhar os dados sujos no buffer compartilhado e atualizar os dados no próprio buffer compartilhado e nos logs de transações que podemos ter 0/1com cada entrada de transação DML para identificar se os dados estão presentes no buffer compartilhado ou não. Isso também pode ser útil ao fazer análises.
Alguém pode me ajudar a entender? Desde já, obrigado!
Dados como páginas de tabela e páginas de índice são sempre acessados por meio de shared_buffers. A única vez que eles são acessados diretamente no disco é quando estão sendo copiados para shared_buffers ou sendo limpos de shared_buffers de volta para o disco. Portanto, não há como "controlar" se é necessário verificar os shared_buffers, pois sempre é necessário verificar os shared_buffers.
Quando uma alteração é feita, a alteração é feita primeiro em shared_buffers e, em seguida, um registro dessa alteração é gravado no buffer de log do WAL (essas duas ações estão fortemente acopladas). Em seguida, o log do WAL é gravado e liberado no disco e, em seguida, os dados sujos em shared_buffers são gravados no disco. Essas ações não são fortemente acopladas, podem haver muitos segundos ou minutos separando-as, mas são sempre realizadas na ordem listada.
Entre o momento em que a atualização é concluída e o momento em que a página suja é gravada (talvez pelo checkpointer ou talvez por outra coisa), ela é bloqueada em shared_buffers. Ele não pode ser removido até que seja gravado e não pode ser gravado até que o registro WAL que o protege seja gravado e liberado.
Portanto, quando seu amigo verifica o saldo dele imediatamente após você confirmar, ele está sendo verificado nos dados "sujos" da tabela bloqueados em shared_buffers.