Имеется WAL, куда последовательно складываются все успешно завершённые транзакции.
Имеется постоянно растущая в памяти масса грязных блоков B-Tree.
Имеется понятие checkpoint - точка в WAL, раньше которой весь журнал (WAL) можно выкинуть.

Как выглядит алгоритм процедуры checkpoint?

Хочется изложение в подобном виде:

1. Останавливаем все транзакции
2. Пишем в WAL последовательно все грязные блоки. WAL отрастает на 64 гига
3. fsync()
4. Пишем все записанные в WAL грязные блоки на их места в табличном файле на те места, откуда они были прочитаны изначально "чистыми"
5. fsync()
6. Пишем в WAL метку "checkpoint", делаем fsync()

Как на самом деле - не знаю. Это версия из головы.
Недостатки: остановка всех транзакций. Вроде бы жизни этого нет, в жизни checkpoint может быть растянут на долгие минуты (для снижения нагрузки на диск), а транзакции продолжают совершаться и записываться в WAL. То есть в WAL в течение многих минут попадают и грязные страницы и новые транзакции вперемешку. В этой ситуации в голову не приходит как можно сделать checkpoint со свойством "до меня можно выкинуть WAL". В голове есть идея как сделать 2 метки checkpoint - "checkpoint start", "checkpoint end" и выкидывать журнал можно до "checkpoint start" только при наличии метки "checkpoint end"...

Как оно на самом деле пошагово исполняется на низком уровне, на уровне write() каждой страницы, flush() и прочих низкоуровневых структур данных?

vyegorov,

2. Насчёт "дублирования смысла нет": предположим размер блока 16 КБ. Мы прочитали чистый блок, потом пришла пара модификаций в этот блок. Две эти модификации легли последовательно в WAL как XLOG-записи. Теперь мы решили перезаписать перезаписать чистый блок прямо там откуда его прочитали грязным - перезаписали половину блока и всё упало. В WAL осталось 2 XLOG записи, говорящие о том, как модифицировать чистый блок, но чистого блока уже нет - на его месте лежит половина непонятно чего и половина нормального блока, т.е. по-сути мусор. При попытке накатить 2 наших XLOG изменения из WAL на чистый блок мы не сможем поднять этот чистый блок - неоткуда. Конец. Поэтому как можно не дублировать блок не понятно.

vyegorov,

Видимо история тут не про checkpoint как точку, а про redo_point + checkpoint про пару.
Правильно я понимаю, что местом, перед которым WAL может быть физически выкинут - это именно redo_point, а не checkpoint, который идёт после и ссылается на redo_point?

vyegorov,

читал такое: "checkpoint" - точка, до которой можно невозбранно выкинуть WAL.
Это бред?

vyegorov,

правильно я понимаю, что выкидывать WAL предполагается до REDO точки, а оставленный WAL должен содержать минимум REDO point и следующий за ней checkpoint? Пространство WAL между REDO точки и CHECKPOINT точки - не выкидываемо. Так?

vyegorovdbms_developer,

Я не понимаю, что вы понимаете под CHECKPOINT точкой.
Все точки — суть позиции в WAL (redo) потоке и регистрируются в контрольном файле.

В частности:
Т.е. всё что случилось до этого момента нам не важно, т.к. данные были синхронизированы и можно удалить WAL.
Всё что после — требуется для восстановления и удаление приведёт к потере данных. И понятно какой файл хватать и проигрывать.

checkpoint я называю некую одну точку в WAL (смещение в байтах от абсолютного нуля WAL). Пытаюсь понять, действительно ли этим словом называется некая такая точка и какие у неё свойства. Могу ли я в любой момент времени невозбранно выкинуть все байты из WAL до этой точки? Понимаю, что словом checkpoint кто-то называет ещё и длинный ПРОЦЕСС.

Вы говорите, что все, что случилось до REDO location можно выкинуть? То есть, всё-таки не до CHECKPOINT, а именно до REDO точки (а CHECKPOINT идёт в WAL-файле после REDO)?

Поизучал доку http://www.interdb.jp/pg/pgsql09.html
Попробовал просуммировать текущее понимание вопроса: https://telegra.ph/postgreSQL-checkpoint-logic-11-14
Просьба сюда не копипастить целиком, я может ещё отредактирую детали или читабельность.

Ещё интересно: в чём разница между процессом скидывания грязных страниц в Postgres и MySQL InnoDB например. Там какие-то shadow write buffers у них.