непонятка с xmin в текущей транзакции

qwwq
Дата: 21.05.2015 12:49:40
RTFM
xmin

The identity (transaction ID) of the inserting transaction for this row version.


-- пытаюсь отстроиться от записей вставленных в текущей транзакции, т.е. прочитать действительно закоммиченные результаты.

примерно так :

SELECT * FROM tabname WHERE 
		NOT xideq( xmin
				,(txid_current() % (4294967296)) ::text::xid
				)
		;

(см 17470725)

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

конкурентов по записи в аудит нет.

-- вижу, что полученные как "видимые" id -- присвоены в той же транзакции. (по 2 записи на id).
начинаю смотреть xmin и (txid_current() % (4294967296)) нотификацией -- вижу, что xmin медленно растёт. а (txid_current() % (4294967296) ) -- стабилен. Совпадение -- только в первой записи -- двух.

NOTICE:  	ev_id 8071,_xmin 13530822,_xmax 0,_txid_current 13531155;
NOTICE:  	ev_id 8071,_xmin 13530822,_xmax 0,_txid_current 13531155;
NOTICE:  	ev_id 8073,_xmin 13531157,_xmax 0,_txid_current 13531155;
NOTICE:  	ev_id 8073,_xmin 13531157,_xmax 0,_txid_current 13531155;
NOTICE:  	ev_id 8075,_xmin 13531159,_xmax 0,_txid_current 13531155;
NOTICE:  	ev_id 8075,_xmin 13531159,_xmax 0,_txid_current 13531155;
NOTICE:  	ev_id 8077,_xmin 13531161,_xmax 0,_txid_current 13531155;
NOTICE:  	ev_id 8077,_xmin 13531161,_xmax 0,_txid_current 13531155;


куда крестьянину податься ? Почему xmin записей вставленных одной транзакцией растет в процессе транзакции? [это всё -- ещё до коммита]

основной вопрос:
как правильно закрыть глаза на всё то и только то, что вставлено в текущей транзакции ?


вообще-то видел вот это 16698801 там автор не делает поправки на цикличность.
поэтому тогда не придал.

но поправка не спасает (или речь о разных транзакциях)

select 4359781591 % (4294967296) ,  62312404
---------------
64814295;62312404


т.е. реально в записях одной транзакции xmin растет (и это происходит без привлечения какой--либо механики по froze (когда надо двигать уже массово и движком "to prevent..." и т.п.)

почему же в справке про это как-то не особо видно ?


//вопрос факультативный, советы вида "а что вы делаете -- не надо этого делать" -- несколько неуместны.
Я , судя по справке, полагал, что у меня есть инструмент отстроиться от записей, изменённых в текущей транзакции -- из неё же (не следя за всей логикой транзакции, а врезавшись в некую точку простеньким инструментом) -- и вот это полагание оказалось ложным. пичалька.
Maxim Boguk
Дата: 21.05.2015 13:59:29
qwwq,

А попробуйте тоже самое сделать запустив транзакцию с уровнем изоляции REPEATABLE READ.
Если это поможет (не факт но мне кажется что должно) - я попробую рассказать что именно происходит.
Кратко: в REPEATABLE READ каждый новый запрос работает с новым snapshot (и фактически с новым xmin).
Примечание - это только теория.

--
Maxim Boguk
www.postgresql-consulting.ru
qwwq
Дата: 21.05.2015 14:08:33
Maxim Boguk,

ок, попытаюсь.

пока грешу на т.н. subtransactions
там несколько триггеров внутри отрабатывает с обработкой исключения
и только один из них -- аудиторский
реально последовательность xmin,current_xtid, ctid в табличке аудита (куда я current_xtid() пишу через DEFAULT) примерно такая:

13535604;13535604;5
13535606;13535604;10
13535604;13535604;16
...............
...............
13539602;13535604;21991
13535604;13535604;21997
13539604;13535604;22002
13535604;13535604;22008
13539606;13535604;22013


и пролезть через поиск их в xip_list текущего снапшота, похоже не удастся. могу заблуждаться.
qwwq
Дата: 21.05.2015 14:39:30
1. REPEATABLE READ повёл себя точно так же.

т.е. вопрос, вероятно, в том, как выяснить , что лежит в xmin -- "txids of subtransaction" OR txids of transaction

и как выяснить предка, если это subtransaction

(хотя бы в момент самой этой транзакции, когда нам "дано в ощущения" несколько больше, чем xmin)
qwwq
Дата: 21.05.2015 14:44:24
OFFTOP:

вопрос
а xmin длиной с bigint пока не планируется ?
qwwq
Дата: 21.05.2015 15:15:14
выкрутился, кааца:
		NOT /* xideq( xmin
				,(txid_current() % (4294967296)) ::text::xid
				)
			*/
			txid_current() = ev_txid -- я болван

в моем случае это специальная табличка, в которой есть зафиксированный txid_current() . а он -- стабилен , даже при наличии обработок исключения. (pgq--батчевание на этом же собрано, похоже)

но что в общем случае я видеть, что моё, свеженажитое, - а что уже закоммиченное -- не умею -- печально.
Maxim Boguk
Дата: 21.05.2015 16:00:31
qwwq,

Расширение xmin/xmax до bigint увеличит tuple header c 24 байт до 32 байт (что очень печально) и гарантированно сломает pg_upgrade.
Разговоры об этом давно идут но пока не нашлось настоящего буйного чтобы это продавить или хотя-бы реализовать в виде прототипа.
Идея с кучей плюсов и с кучей же минусов.

--
Maxim Boguk
www.postgresql-consulting.ru
qwwq
Дата: 21.05.2015 16:15:59
Maxim Boguk,

я не к тому, чтобы ссылаться на xmin как на txid_current() -- они, с учетом сущ-я сабтранзакций, видимо разные (от begin до end блока исключений вероятно болтается то, что обзывается сабтранзакцией, со своим txid). и дело не в длине, а в savepoint-ах.


это был офтоп -- очень печально иметь базу большого объёма с большим же потоком транзакций -- воркеры всё время затыкаются, сколько не увеличивай их число, одним только to prevent wraparound--ом. [надо успеть прокрутить в цилиндрической координате объём базы за время, за которое набегает длина цилиндра "в попугаях" -- транзакциях -- белка в колесе, одним словом]

хоть слово [опцию conf-а] какое-то надо бы придумать -- запретить, например, стандартным воркерам заниматься wraparroun-ом, пусть движок сам поднимает сверх лимита, что ли. всё равно -- оно без этого жить не может -- вот пусть сам себе и поднимает, .

а для малых -- оно действительно дешевле не шевелиться. во всех смыслах.
PgSQLAnonymous
Дата: 21.05.2015 16:55:11
Maxim Boguk
qwwq,

Расширение xmin/xmax до bigint увеличит tuple header c 24 байт до 32 байт (что очень печально) и гарантированно сломает pg_upgrade.
Разговоры об этом давно идут но пока не нашлось настоящего буйного чтобы это продавить или хотя-бы реализовать в виде прототипа.
Идея с кучей плюсов и с кучей же минусов.

А Вы не могли бы рассказать подробнее именно о куче плюсов и минусов?

Я сходу вижу только то, что (+) концепцию FREEZE можно выбросить, но (-) во всех маленьких базах в каждой записи будут 4 нулевых байта, которые этой базе никогда не пригодятся.
qwwq
Дата: 21.05.2015 17:04:57
PgSQLAnonymous,

идеальной была бы опция длины полей при создании кластера.
тогда маленькие остались бы с малой накладной по длине
а большие -- с малой (даже 0-вой) накладной по частоте оборачивания freeze

в принципе, если ну очень быстро крутить транзы -- писать и стирать, писать и стирать -- то и очень маленькую БД можно заставить прокручиваться -- всё определит поток транзакций