тестовая табличка (user_id, money), делаю select xmin, xmax, * from users вне транзакции, получаю: (997, 997, 1, 100), (999, 0, 2, 1000)
Не понимаю, как такое может быть, что строка с xmin = xmax попала в select, если строка помечена удаленной (xmax = 997) в какой-то старой транзакции? 🤔
p.s. разбираюсь с mvcc:)
Смотрите ещё cmin,cmax (И да, у этих двух всё сложно с хранением, там поля как-то пересекаются).
CREATE TABLE test_table ( user_id bigint PRIMARY KEY, amount numeric NOT NULL ); INSERT INTO test_table(user_id, amount) VALUES (1, 0), (2, 1); INSERT INTO test_table(user_id, amount) VALUES (1, 6) ON CONFLICT(user_id) DO UPDATE SET amount = 7; SELECT ctid, xmin, xmax, user_id, amount FROM test_table; См. https://www.postgresql.org/docs/current/ddl-system-columns.html и по ссылкам.
Спасибо, разобрался. Для ленивых: It is possible for this column to be nonzero in a visible row version. That usually indicates that the deleting transaction hasn't committed yet, or that an attempted deletion was rolled back.
Еще блокировки строк используют xmax + информационные биты для обозначения блокировки. Поэтому, даже SELECT FOR UPDATE может выставлять xmax, хотя это и не говорит о том, что версия строки удалена
понял, спасибо)
Это HOT UPDATE , видимо, так это преобразовал? Да, вижу HEAP_XMAX_LOCK_ONLY в pageinspect. Немного жаль, что нельзя не-суперюзерскими средствами это получить.
Ну а зачем это пользователям, казалось бы?
Затем жэ, зачем xmin/xmax. Посмотреть, что вообще происходит.
(И вообще, давно пора read uncommitted давать. А то пуризм какой-то. Хотите ломать свою БД — держыте лом, не моё, не жалко.)
Вот пускай DBA и смотрит (а то я видел "замечательные" схемы, где системные поля пытались использовать с бизнес-целями — "конец немного предсказуем"). Т.е. и в том, что xmin/xmax видны обычным пользователям, я как-то пользы особо не вижу.
(Пожав плечами) да кто не видел.
В PostgreSQL и так есть Read Uncommitted. То, что Вы имеете в виду, называется "dirty read".
Обсуждают сегодня