Pull to refresh

Comments 11

Заранее извиняюсь, если мой вопрос глупый, т.к. я очень далек от разработки БД.
Я правильно понимаю, что в момент, когда с начала выполнения транзакции прошло 2^31 других транзакций бОльшая часть из этих 2^31 уже выполнена и их номера хранить не надо? Вопрос к тому, что разве нельзя по достижению середины круга проходить по всему счетчику и убрать оттуда все лишнее, оставив только те транзакции, которые еще не выполнены? Таким образом, мы сохраним порядок ­транзакций, что нам и требовалось?
выполнена и их номера хранить не надо

именно это и делает процесс вакуум, он проставляет специальный номер транзакции — FrozenXid (так было до 9.5), а в 9.5 проставляется специальный Hint Bit.


Вопрос к тому, что разве нельзя по достижению середины круга проходить по всему счетчику

счетчик прописал свой номер в данных, и идти надо по данным, а не по счетчику. На больших данных это накладно. Поэтому существуют процессы, которые выполняют это в фоне.


Таким образом, мы сохраним порядок ­транзакций, что нам и требовалось?

в идеале все работает "само", факап описанный в статье произошел из-за того, что 8 дней выполнялся процесс работающий в своем снимке данных, можно сказать в своей транзакции.

Если вдруг появится залипшая транзакция такое может случится. Просто в этом случае процесс был более менее запущен вручную.
Счетчик транзакций имеет размер 32 бита, то есть может хранить примерно четыре миллиарда значений. Это, конечно, не так уж много. Звучали предложения сделать его 64-битным, однако не стоит забывать, что в этом случае за счет накладных расходов заметно возрос бы объем базы — ведь в каждой строке хранятся xmin и xmax.
По-моему лишние 8 байт на строку в наше время не такая уж и большая плата за отсутствие таких проблем в обозримом будущем. По крайней мере, как опцию можно было бы сделать.
Большинству такое обозримое будущее — это бесконечность. Такие ситуации могут встретиться лишь на высоконагруженных системах. А для этого случая уже сделан патч, поэтому в данном случае краха уже не случится.
Для такого случая — да. В будущем могут вскрыться и другие. Проще предотвратить, чем лечить.
Размер заголовка строки уже 24 байта (это минимум, при наличии больше чем 8-ми NULL полей будет ещё больше). Если строки большие, то 8 лишних байт роли не сыграют, но если у вас сотни миллионов компактных строк, то тут и 24 байта выглядят не всегда подъемными.
Если у нас сотни миллионов строк это всего навсего пара лишних гигабайт. Гораздо гораздее версионность системы и WAL будут кушать место чем лишние 8 байт на запись. Хотя с другой стороны, вспоминая экономию на временных метках и «проблему 2000», всегда есть возможность попрограммировать в будущем. Зачем напрягаться сейчас, когда есть возможность переложить на будущие поколения погромистов %)
Sign up to leave a comment.