Может ли жесткий перезапуск машинного хостинга PostgreSQL изменить последовательность PostgreSQL?

Question

У меня этот случай на моем рабочем столе.

Клиент перезапустил (не менее 2 раз) машину, на которой работал PostgreSQL. После этого изменяется следующая последовательность последовательности в одном столбце. не

Последнее значения перед повторным запуском было 582. После перезагрузки он должен вернуть 583, но вместо этого он вернулся 615.

Я проверил все возможные журналы, из системных журналов Linux через журналы PostgreSQL до наших журналов приложений, не зрения для любого вызова nextval в этой строке.

Так что я попробовал бредовую идею, и переводить числа в биты ..

583 in bits: 0010 0100 0111 
615 in bits: 0010 0110 0111 

Существует только один бит разница. Итак, возможно ли, что один бит перепутался с жестким перезапуском ???

На самом деле не так много вариантов, как это было бы в следующем заглавии 33 раз за это время. Разница во времени между вызванным вызовом 582 и возвратом 615 составляет только час или около того, и в это время ПК дважды перезапускался. Да, это долгое время в программировании, но в это время нет звания вызова nextval.

Edit # 1:

Я проверил cache_value, это 1 (как это, вероятно, должно быть). Также increment_by тоже 1. Поэтому не должно быть выделенных значений. Код, вызывающий nextval, связан с аппаратным переключателем (датчик Cashbox), когда он активирован, он обнаруживает состояние Cashbox и вставляет его в таблицу, идентификатором которой является эта последовательность. Перед добавлением новой строки сделаны довольно тяжелые выделения, поэтому, если она была вызвана, в журналах приложений или журналах PostgreSQL появятся некоторые следы.

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

Answer 1

См. this Postgres documentation for details on how sequences are generated in Postgres.

Процитирует документацию:

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

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

documentation on sequence generation может помочь вам определить, как установить размер кеша последовательности и какое значение нужно «перезапустить».

Дополнительно: В вашей ситуации это звучит так, как будто вы может иметь бизнес-правило, требующее от первичных ключей в таблице, чтобы быть как последовательным, и бесщелевым (без пробелов между последовательностями). A.Элеин Мастейн предлагает нетривиальный solution to generating so called "gapless sequences".