Partisan MЭтому автору вопроса я уже отвечал в linux.org.ru , что его ссылка не открывается. Значит, за долгое время он так и не решил эту пустячную проблему. Значит, там неправильно описаны внутренности работы, раз ему настолько не хватает компьютерной грамотности.
В вашей компьютерной грамотности у всех ещё большие сомнения ввиду (1) вашей неспособности решить свою проблему с открыванием любых существующих в интернете доменов, (2) незнания проекта telegra.ph и его реальных авторов.

Partisan MУ меня проблема? Вы с 16 ноября не можете добиться , чтобы работала ссылка на вашу статью. Плевал я на ваш telegra.ph . Вы там поместили статью - вы и добивайтесь, чтоб ссылка работала . Вы ничего не сделали для этого. Не знающему, но адекватному автору вопроса я мог бы задать наводяшие вопросы для выяснения конкретной причины и посоветовать, как исправить. Но у вас большое самомнение при малых знаниях, поэтому помогать вам бессмысленно.

Ищите ещё один форум для создания вашей темы. Но результат будет тот же.
Да, у вас проблема - не можете открыть один из существующих в мире доменов, принадлежащих Павлу Дурову.

Hawkmoondbms_developerбольшие сомнения ввиду вашей неспособности решить свою проблему с открыванием любых существующих в интернете доменов
Аффтар жжот. И надейится, что ВПН у всех отовсюду. Особенно из недогоскорпорации. Особенно с их службами безопасности. Особенно важно всем прочитать статью, рискуя разговором с СБ по поводу корпоративной этики относительно анонимайзеров. Даже если технически доступ оставили.

Вам сколько, 18, юноша? А у некоторых финансовые обязательства посерьезнее вас. И ваш вопрос - ваши и проблемы.
Я и не говорю, что мой вопрос - чья-то чужая проблема.
Просто я дал ответ на странные нападки на меня о том, что я не могу решить проблему с открываемостью какого-либо домена у кого-то там. И ещё меня порадовала логика о том, что написанное по ссылке не верно, хотя автор этой логики даже не смог написанное прочитать.

Я могу позволить себе подождать, пока кто-то прочитает этот текст и прокомментит что-то по его сути.
Заче мне читать о том, что я как-то причастен к не открываемости этой ссылки - не сильно понятно.
Ну не открылась у тебя какая-то ссылка, возможно тебе от этого обидно, но ты просто можешь пройти мимо, в чём твоя проблема?)

Павел Лузановdbms_developer,

Ссылку открыть не могу, но точно знаю, что работа контрольной точки правильно описана здесь .
Нет, она здесь не описана никак.
Тут описаны только ограны управления на панели сисадмина, которые надо крутить.

qwwqdbms_developer,

ходил мимо
но осадочек остался
а именно -- цель тс в рекламе домена дуры павловой, а не в обсуждении какого-либо текста
Ничего страшного, это бывает!

vyegorovdbms_developer,

Мне сразу не нравится начало.
Вы говорите о Key-Value системах, о наличии там WAL (?) и периодических снимках на диск.
Затем следует В Postgres имеются похожие концепции.
Я не согласен с тем, что Postgres похож на Key-Value, всё ровно наоборот — Key-Value системы копируют принципы работы RDBMS.
Я уже давал ссылку на https://cs.stanford.edu/people/chrismre/cs345/rl/aries.pdf

Далее как это происходит в Postgres.
Раз в час (например) наступает момент сброса состояния системы из ОЗУ в снепшот.
Ну нельзя же так. Вам дали ссылку на официальную доку, где расписано когда, куда и как “наступает момент”.

-----

Если вы хотите объяснить принципы работы, то надо начинать с концепции, а не сразу в детали лезть.
Хотя бы объяснить — а зачем такой механизм был сделан?..
И с терминами надо бы определится, солянка какая-то…
По большому счёту Postgres и любая другая RDBMS -- это некая сложная логика, навёрнутая поверх на Key = Value.
Key = Value - это основа. В Postgres Key - это ключ первичного индекса (возможно, составной), а Value - весь Tuple (вся строка; либо целиком, либо только отсутствующие в Key колонки).
Это всё как раз базовое, не требующее пояснений. То, с чего мы стартуем в нашем понятийном аппарате.

Hawkmoondbms_developer,

ваш понятийный аппарат не совместим с выработавшимся лексиконом в сфере DBMS.

Value как Tuple - это аццки неверно.


Говоря о том, что кортеж = значению, Вы игнорируете понятия "домен" и "значения допустимые на домене". А также то, что кортеж состоит из указанных доменов.


Короче, студент, незачет.
Либо крестик dbms из ника сними, либо привыкай к сложившейся терминологии именно в DBMS
Это не мой аппарат, а элементарные аналогии.
Tuple - это просто набор полей, который с точки зрения Key=Val лежит как Val. Это аццки верно. Далее в ход идёт логика столбцов-таблиц-вот-это-всё, которая выдергивает из этого Val разные колонки. Домены и прочая хрень - это уже "как трактуются байтики внутри строчки Val кодом верхнего уровня". А в основе Key=Val, лежащий в B+-Tree.

С точки зрения системы хранения страничек Б-Дерева, нет ничего кроме страничек, набитых Key=Val, где в Val эта ваша вся доменно-столбцовая хрень и нам на уровне системы хранения страничек Б-Дерева совершенно пофиг на это. Непонимание этой элементарщины - ну это вам низачот, вы застряли на уровне понятий из высокоуровневой книжки и не понимаете, что на нижнем уровне в страничках лежит тупейший набор Key=Val. Вв, что называется, перечитали вумных книжек про реляционный мир и не шарите в основах.

Dimitry Sibiryakov"Когда в руках молоток всё вокруг выглядит как гвозди."
Отличный комментарий, наверное он как-то относится к теме.

Напоминаю: мы говорим только о системе хранения, которая ничего кроме последовательности команд, меняющих блоки Б-Дерева и набора этих блоков, в каждом из которых лежит просто отсортированный по Key массив Tuple (и больше ничего), не видит.

Melkijdbms_developerНапоминаю: мы говорим только о системе хранения, которая ничего кроме последовательности команд, меняющих блоки Б-Дерева и набора этих блоков, в каждом из которых лежит просто отсортированный по Key массив Tuple (и больше ничего), не видит.
Говоря о checkpoint в postgresql?
Да до лампочки чекпойнтеру данные. Блок в памяти грязный и нам надо его записать для этого чекпойнта? Замечательно, пишем весь блок как он есть на диск и идём к следующему.

Ну и если говорить про таблицы - то никакого btree там нет. Обыкновенная куча, абсолютно ни по какому признаку не сортированная.Отлично, первый человек, догадавшийся, что можно забить на то, что там в блоке. Важно только что он грязный, ага.

Ну а B+-Tree там есть, надо признать.

Melkijdbms_developerНу а B+-Tree там есть, надо признать.
Неа.
Деревья (разные!) могут быть в содержимом страниц конкретных access method (AM)
Может быть потом когда-нибудь допилят pluggable storage и опять же на уровне чуть выше страницы данных можно будет найти дерево.
А heap - банальная вульгарная куча
Это уже не важно. Чаще всего там какое-то B+-Tree.

Hawkmoondbms_developerС точки зрения системы хранения страничек Б-Дерева, нет ничего кроме страничек, набитых Key=Val, где в Val эта ваша вся доменно-столбцовая хрень и нам на уровне системы хранения страничек Б-Дерева совершенно пофиг на это.

Нет, студент, ты так слона не продашь диплом/диссер не защитишь.
потому что в СУБД под значением подразумевается допустимое значение домена. И если ты будешь замечательно рассказывать о ключе-значении чуваку, знающему реляционную АЛГЕБРУ, то ты порвешь мозг ему, также как порвал мозг всем тут.



Только проблема будет в том, что обладатель ученой степени - он, а защищаешься ты.
И со своим "ну плутон это земля, что тут непонятного. И марс земля, и луна земля." и агрессивным навязыванием своего языка, вместо использования сложившегося термина "планета/планетоид" пойдешь дорабатывать свою работу ты.

Я бы как рецензент отправил бы человека, приславшего такую статью, далеко.
Э-э-э, мы не говорим про СУБД и про реляционную алгебру.

Melkijdbms_developerЭто уже не важно.
Так если не важно - то при чём тут postgresql?
Берёте Transactional Information Systems Theory, Algorithms, and the Practice of Concurrency Control and Recovery авторства Gerhard Weikum и Gottfried Vossen и читаете. Про чекпойнты там тоже написано.
Мы обсуждаем систему checkpoint в постгресе. А реляционная алгебра и что точно хранится в страничках при этом - не очень важно.
Ваш кэпушка.

Alex URSvyegorovAlex URS,

pg_prewarm и цитата Тома — они несколько о другом.
Мы тут обсуждаем Нам рассказывают про механизмы попадающие под ‘D’ (Durability), и там важна другого рода производительность.

если брать в целом - согласен
статью читал, но не понимаю одно:
если нам впаривают, что Key = Value, то это не так. Реляция это связь, но не Key - Value.

Нет, этого вам не впаривают.
Игнорируйте впустую возбудившихся.

Scott Tigerdbms_developer, главная ошибка автора текста по ссылке состоит в том, что он пытается натянуть видимо хорошо ему знакомую терминологию из условного Redis на совершенно по-другому устроенный PostgreSQL. Как результат, понять логику рассуждений сложно, ибо она построена на совершенно абсурдных предположениях. Для начала надо понять, что для постгреса неприменима логика восстановления в памяти состояния из дисковой копии ("снапшота"), ибо первичным является собственно состояние на диске, а память используется как буфер, временно хранящий обрабатываемые данные, причём размер этого буфера обычно несопоставимо меньше объёма данных, хранящихся на диске (в файлах).
Это понятно, но это не принципиально для темы обсужления.

Ясно, что для СУБД типично то, что дисковое/ленточное/бумажное хранилище первично по отношению к памяти. В этом смысле СУБД не пытается накатить состояние памяти из "снепшота", чтобы работать, и ОЗУ рассматривается чисто как кеш. Но это совершенно не отличается от того, как если бы у нас существовала некая Key=Value, которая умеет вытеснять из памяти часть данных и по необходимости ходить за ними на диск. Я считаю, что в современном мире систем хранения эта граница давно уже размыта. Что считать
"in-memory" хранилкой, что "дисковой" - уже строго деления давно нет. Все они держат что-то в памяти, что-то имеют право держать на диске. Если система держит на диске 95% своих данных, то "in-memory" или нет? А если через 1 минуту подгрузила всё в память и больше не выгружала - она стала "in memory" от этого? В общем это всё софистика с точки зрения темы топика. Мы можем реализовать тот же Redis на базе B+-Tree, а не на базе хеш-таблички и научить Redis при старте не зачитывать в память всё, а подгружать блоки B+-Tree при необходимости, а при желании скинуть что-то на диск, помимо записи журнала, иногда делать тот же самый checkpoint процесс со скидыванием грязных страничек.

Так что тема разговора просто про способ синхронизировать с диском набор грязных блоков, реализованный в Постгресе в виде постгресного checkpoint процесса. Что там в этих блоках лежало - многоверсионные кортежи, реляционно связанные с чем-то там ещё или просто россыпь Key=Value - имеет нулевую важность.

Alex URSdbms_developerЯсно, что для СУБД типично то, что дисковое/ленточное/бумажное хранилище первично по отношению к памяти. В этом смысле СУБД не пытается накатить состояние памяти из "снепшота", чтобы работать, и ОЗУ рассматривается чисто как кеш. Но это совершенно не отличается от того, как если бы у нас существовала некая Key=Value, которая умеет вытеснять из памяти часть данных и по необходимости ходить за ними на диск. Я считаю, что в современном мире систем хранения эта граница давно уже размыта. Что считать
"in-memory" хранилкой, что "дисковой" - уже строго деления давно нет. Все они держат что-то в памяти, что-то имеют право держать на диске. Если система держит на диске 95% своих данных, то "in-memory" или нет? А если через 1 минуту подгрузила всё в память и больше не выгружала - она стала "in memory" от этого? В общем это всё софистика с точки зрения темы топика. Мы можем реализовать тот же Redis на базе B+-Tree, а не на базе хеш-таблички и научить Redis при старте не зачитывать в память всё, а подгружать блоки B+-Tree при необходимости, а при желании скинуть что-то на диск, помимо записи журнала, иногда делать тот же самый checkpoint процесс со скидыванием грязных страничек.

Так что тема разговора просто про способ синхронизировать с диском набор грязных блоков, реализованный в Постгресе в виде постгресного checkpoint процесса. Что там в этих блоках лежало - многоверсионные кортежи, реляционно связанные с чем-то там ещё или просто россыпь Key=Value - имеет нулевую важность.

смешались в кучу кони, люди (с)
1. по поводу нулевой важности - прочитайте про архитектуру Berkeley DB
2. система in-memory - это не совсем то, что вы пишите - это не место - это механизм, который подразумевает хранение в in-memory как минимум индексов к объекту

вообще я не понимаю такую вещь - SQL на порядок надёжнее, чем NOSQL из за математического способа структуризации, которого в NOSQL нет - как можно от NOSQL "тянуть" checkpoint в SQL(RDBMS) - это не логично
Не очень понял в чём вопрос.
У вас есть B+-Tree в большом файлике.
Вы нагрузили в память каких-то блоков этого B+-Tree, какими-то элементарными операциями меняете содержимое этих блоков, возможно порождаете новые.
Задача: хотелось бы скинуть на диск изменённые блоки. Как-нибудь.

Checkout process в Постгресе решает эту задачу своим способом.
Этот способ и обсуждается.
Чё там в этих блоках валяется - строки таблиц, Key=Value или ещё какая хрень - вообще пофигу. SQL тоже.