RTFM

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

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



(см 17470725 )

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

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

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




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

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


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

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




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

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


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

Maxim Boguk,

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

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




и пролезть через поиск их в xip_list текущего снапшота, похоже не удастся. могу заблуждаться.

1. REPEATABLE READ повёл себя точно так же.

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

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

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

OFFTOP:

вопрос
а xmin длиной с bigint пока не планируется ?

выкрутился, кааца:


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

но что в общем случае я видеть, что моё, свеженажитое, - а что уже закоммиченное -- не умею -- печально.

Maxim Boguk,

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


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

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

а для малых -- оно действительно дешевле не шевелиться. во всех смыслах.

PgSQLAnonymous,

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

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

Misha Tyurin http://www.postgresql.org/docs/9.4/static/sql-createtrigger.html

Deffered trigger

И там смотрите всё по now например. Вы все таки решение не ту задачу и не так
о, наш тигра набежал
даже наскочил
короче -- напрыгнул

чего то сказать хотели, скакучий вы нашЪ ?
с тренингов выпустили ?

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

кто, кстати, тут хоть что-то говорил про констрейнт триггера ?
ау ?
-- да и про задачу никто не заикался

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

и зашит он, инструмент сей, в xmin -- ну незакомиченную точно ещё не пофризили.

Но тут-то меня справкой и набманули, подлые намбанщики.
до чего довёл rtfm этот фигляр ПЖ.
и возник естественный факультативный вопрос -- как восстановить утерянную уверенность.


по факультативному вопросу имеете заявить? полосатенький вы нашЪ
или now() -- вот вашЪ ответ ? на неподготовленной табличке ? и now() ? а как оно, в неподготовленную-то проникнет ? а в подготовленную-то я эвон current txid положу, оно тоже работает. и даже лучше.

Misha Tyurinqwwq,

Нету у вас никакого инструмента. Есть видимость txid в снапшоте

http://www.postgresql.org/docs/9.4/static/functions-info.html
Table 9-61. Transaction IDs and Snapshots


Это да. Но это не про вас. Потому что вы делаете как всегда не то) вас бы в правильное русло так сказатьо, любезный кинул в меня ссылкой, которую я давно облазил [по диагонали, по другому давно разучился] на предмет наличия разъяснений что ж такое "txids of subtransactions"
хотя бы вот тут
авторThe list does not include txids of subtransactions.
но "ува, ува, и голова барабартает с плеч"

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

внимание, вопрос :
-- где тут было о том, чем я занимаюсь ?
и вопрос 2:
-- куда вам следует идти в случае, если вы в этой теме не найдёте ответа на первый ?

вот вот, идите, идите.

Misha TyurinВам только одно поможет -- чтение до полного прояснения

http://www.opennet.ru/docs/RUS/smart_question/
миша, миша
-- вам-то уже точно ничего не поможет

это, как вы помните, я диагностировал с первого наблюдения уже много лет тому назад

В общем -- пока фиксирую неполноту и бессвязность ртфм-а в части термина "subtransaction"

поиск подтверждает мою версию трактовки :
авторsubtransaction commit (RELEASE SAVEPOINT or exit from a PL/pgSQL exception block).

и соответственно справка в части процитированной в старте

не полна -- т.к. в xmin может валяться и "subtransaction id" , как показали замеры.
[не говоря о заморозке и прочих тонкостях]