Комментарии 11
Заранее извиняюсь, если мой вопрос глупый, т.к. я очень далек от разработки БД.
Я правильно понимаю, что в момент, когда с начала выполнения транзакции прошло 2^31 других транзакций бОльшая часть из этих 2^31 уже выполнена и их номера хранить не надо? Вопрос к тому, что разве нельзя по достижению середины круга проходить по всему счетчику и убрать оттуда все лишнее, оставив только те транзакции, которые еще не выполнены? Таким образом, мы сохраним порядок транзакций, что нам и требовалось?
Я правильно понимаю, что в момент, когда с начала выполнения транзакции прошло 2^31 других транзакций бОльшая часть из этих 2^31 уже выполнена и их номера хранить не надо? Вопрос к тому, что разве нельзя по достижению середины круга проходить по всему счетчику и убрать оттуда все лишнее, оставив только те транзакции, которые еще не выполнены? Таким образом, мы сохраним порядок транзакций, что нам и требовалось?
выполнена и их номера хранить не надо
именно это и делает процесс вакуум, он проставляет специальный номер транзакции — FrozenXid (так было до 9.5), а в 9.5 проставляется специальный Hint Bit.
Вопрос к тому, что разве нельзя по достижению середины круга проходить по всему счетчику
счетчик прописал свой номер в данных, и идти надо по данным, а не по счетчику. На больших данных это накладно. Поэтому существуют процессы, которые выполняют это в фоне.
Таким образом, мы сохраним порядок транзакций, что нам и требовалось?
в идеале все работает "само", факап описанный в статье произошел из-за того, что 8 дней выполнялся процесс работающий в своем снимке данных, можно сказать в своей транзакции.
Если вдруг появится залипшая транзакция такое может случится. Просто в этом случае процесс был более менее запущен вручную.
Ждем конфигурируемого "snapshot too old" :)
Счетчик транзакций имеет размер 32 бита, то есть может хранить примерно четыре миллиарда значений. Это, конечно, не так уж много. Звучали предложения сделать его 64-битным, однако не стоит забывать, что в этом случае за счет накладных расходов заметно возрос бы объем базы — ведь в каждой строке хранятся xmin и xmax.По-моему лишние 8 байт на строку в наше время не такая уж и большая плата за отсутствие таких проблем в обозримом будущем. По крайней мере, как опцию можно было бы сделать.
Большинству такое обозримое будущее — это бесконечность. Такие ситуации могут встретиться лишь на высоконагруженных системах. А для этого случая уже сделан патч, поэтому в данном случае краха уже не случится.
Размер заголовка строки уже 24 байта (это минимум, при наличии больше чем 8-ми NULL полей будет ещё больше). Если строки большие, то 8 лишних байт роли не сыграют, но если у вас сотни миллионов компактных строк, то тут и 24 байта выглядят не всегда подъемными.
Если у нас сотни миллионов строк это всего навсего пара лишних гигабайт. Гораздо гораздее версионность системы и WAL будут кушать место чем лишние 8 байт на запись. Хотя с другой стороны, вспоминая экономию на временных метках и «проблему 2000», всегда есть возможность попрограммировать в будущем. Зачем напрягаться сейчас, когда есть возможность переложить на будущие поколения погромистов %)
Патч, кстати, принят. Будет включен в ближайший минорный релиз.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PostgreSQL: Случай в вакууме