Про "Wraparound ID транзакції"

Тепер я читаю документ про "Обмеження ідентифікатора транзакцій", але є щось, чого я насправді не розумію, документ - це наступний URL http://www.postgresql.org/docs/9.0/static/routine-vacuuming .html # ВАКУУМ-ДЛЯ ЗАПАСНУВАННЯ

23.1.4. Запобігання помилкам ідентифікатора транзакції

Семантика транзакцій MVCC PostgreSQL залежить від можливості порівняння номерів ідентифікатора транзакції (XID): версія рядка із вставкою XID, що перевищує XID поточної транзакції, є "в майбутньому" і не повинна бути видимою для поточної транзакції. Але оскільки ідентифікатори транзакцій мають обмежений розмір (32 біти), кластер, який працює протягом тривалого часу (понад 4 мільярди транзакцій), зазнав би обертання ідентифікатора транзакції: лічильник XID завершується до нуля, і всі раптові транзакції, що відбулися в минуле здається в майбутньому - це означає, що їх вихід стає непомітним. Словом, катастрофічні втрати даних. (Насправді дані все ще є, але це холодний комфорт, якщо ви не можете їх отримати.) Щоб цього уникнути, потрібно пилососити кожну таблицю в кожній базі даних хоча б раз на два мільярди транзакцій.

Я не розумію висловлювань "зазнав би ідентифікатор транзакції: лічильник XID завершиться до нуля, і всі раптові транзакції, що були в минулому, здаються в майбутньому - це означає, що їх вихід стає непомітним"

Хтось може це пояснити? Чому після того, як база даних зазнає ідентифікатора транзакцій, обернення, здавалося б, у майбутньому відбудуться транзакції? Коротше кажучи, я хочу знати, чи стане PostgreSQL в ситуації "втрати даних" після завершення ідентифікації транзакції автовакумом。

Для моїх особистих поглядів, ми можемо отримати поточний ідентифікатор транзакції, використовуючи функцію txid_current () для тих, хто виводить 64-бітний і не буде циклічним. Отже, я думаю, що ідентифікатор транзакції вставки з кортежів, який знає, що xmin стане нервовим більше, ніж xid, який отримують функцією tksid_current (). За винятком того, що ви будете використовувати ідентифікатор транзакції скидання pg_resetxlog після вимкнення PostgreSQL Server. Чи правий я ? Дякую

Чому після того, як база даних зазнає ідентифікатора транзакцій, обернення, здавалося б, у майбутньому відбудуться транзакції?

Вони ні. Текст, який цитується, просто пояснює, чому для постгресів потрібно використовувати арифметичний модуль 2 ³¹ (а це означає, що транзакції можуть обертатися до тих пір, поки старі транзакції будуть «заморожені» досить рано):

Звичайні XID порівнюються, використовуючи арифметичну модуль-2 ^ 31. Це означає, що для кожного нормального XID існує два мільярди «старих» і два мільярди, які «новіші»

бути конкретним:

старі версії рядків повинні бути перепризначені XID FrozenXID десь до того, як вони досягнуть старого позначки в два мільярди транзакцій

або загортання XID навколо може спричинити зламування речей. Щоб запобігти цьому, поштові грешки почнуть видавати попередження, а згодом закриються та відмовляться запускати нові трансактони, якщо це необхідно:

Якщо з якихось причин автовакуум не зможе очистити старі XID з таблиці, система почне видавати такі попереджувальні повідомлення, коли найдавніші XID бази даних досягають десяти мільйонів транзакцій від точки обговорення:

WARNING:  database "mydb" must be vacuumed within 177009986 transactions 
HINT:  To avoid a database shutdown, execute a database-wide VACUUM in "mydb". 

(Посібник VACUUM повинен вирішити проблему, як це запропоновано підказкою; але зауважте, що VACUUM повинен виконуватись суперпользователем, інакше він не зможе обробити системні каталоги і, таким чином, не зможе просунути датфроксид бази даних.) Якщо ці попередження ігнорується, система вимкнеться і відмовиться починати будь-які нові транзакції, коли залишиться менше ніж 1 мільйон транзакцій до завершення

Іншими словами, «транзакції, які були в минулому, здаються в майбутньому» і «втрата даних» цілком теоретичні і не будуть спричинені обертанням ідентифікатора транзакцій на практиці.

Блок, який ви вставили, здається, відповідає на питання. Все залежить від логіки, яка використовується для приховування "майбутніх" транзакцій.

Лічильник ідентифікатора транзакції (XID) обмежений 32 бітами, і якщо він коли-небудь досягне цього наступного числа, замість того, щоб замінити стару максимальну транзакцію, він починає свіжим з нуля.

Ну, тепер це нуль, тому PostgreSQL приховує від нього всі транзакції> 0. Тож навіть незважаючи на те, що транзакція №2,147,483,633 трапилася 20 секунд тому, PostgreSQL вважає, що це не відбудеться ще для 2,147,483,633 транзакцій.