хочу получить "неразрывную" (незакоммиченными конкурентами) верхнюю грань некого id (сиквенс) для очереди
//удостовериться в отсутствии конкурентов на момент получения max(id) //

для чего пытаюсь периодически вычитать



ожидая NULL при наличии конкурентов. И не NULL -- в отсутствии.
получаю в массе такое:
10000751643949;3;t
-- т.е. в активных числится 3 транзакции, а на момент вычитки снепшота -- 1.

кому верить ? как объяснить ?
уровни изоляции не влияют.

Warstoneqwwq,

Эм... После вас появились конекты?.. xmax никто не поменяет, а pg_stat_activity...
нет. эксперимент показывает, что в txid_current_snapshot() попадают только транзы, в которых произошли события записи. (надо будет протестить с локом for update -- тут вопросы ). т.е. я открываю транзакцию, а потом в открытом из него dblink спрашиваю снапшот -- конкурента (родителя) --не вижу. если сначала что--то записать в родителе -- то вижу.

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


WarstoneТак дока: http://www.postgresql.org/docs/9.4/static/monitoring-stats.html#PG-STAT-ACTIVITY-VIEW Another important point is that when a server process is asked to display any of these statistics, it first fetches the most recent report emitted by the collector process and then continues to use this snapshot for all statistical views and functions until the end of its current transaction.

да, вырисовывается алгоритм -- читаем в read commited max(id) . следующим стейтментом (можно даже транзакцией) -- получаем подтверждение из pg_stat_activity (тут можно выколоть служебные процессы и свои известные, обслуживающие эту вашу логику) -- что кандидатов на запись нет (т.е. все полученные nextval к моменту [уже этого] запроса пришли в commit или rollback ) -- и ,если да, -- фиксируем грань в журнале.

жаль только -- редко удача будет выпадать. будут большие слепые пятна при нагрузке.

qwwq... как лондайст батч собирает...
поправка.
это кухня pgq

Maxim Boguk,

вы правы. лок генерирует txid_current(). xmin после него фиксирован для всех снепшотов в транзакции.

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

как только начались -- xmin фиксировано. ( с точностью до наличия более ранних пишущих конкурентов)

кажется, если запросить в лоб txid_current() -- то тоже сразу фиксируется номер транзакции.
да и стендбай ругается:




т.е. -- для меня важно -- если есть вероятность , что nextval вычитали до события [любой] записи в [какой-либо из конкурирующих] транзакции -- мне без вариантов надо пользоваться pg_stat_activity ( в read commited, строго после вычитки грани)

p2.qwwq//удостовериться в отсутствии конкурентов на момент получения max(id) //почему бы не блокировать общий ресурс каждым конкурентом?
зачем ? и какой?

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

задача: ~

есть уже реализованная система . эта часть -- голая вставка с датчиков. никакого узкого места нет. не нужно оно там.

встаёт задача -- поделиться данными с третьими лицами.
асинхронно

решение --

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


либо, [что я пытаюсь надыбать] -- журнал [запись] достигнутого (уже отправленного) + журнал отсечки -- запись наибольшего id гарантированно меньшего всего, что ещё может быть в dirty. -- и строго последовательная [или таки с журналом, но в объёме наличных читателей, а не суточного простоя] отправка в диапазоне между двумя найденными гранями, с записью в журнал достигнутого (тут очередь нам не мешает -- это асинхронно -- не пролезет днём --- ночью нагрузка спадёт немного). тут тоже вечно распухшие таблички журналов с одной записью. но таблиц--блокировочников в пж пока нет. а для таких целей они были бы идеальны. утешение -- индексировать их не нужно обязательно . можно ещё посмотреть в сторону использования вместо {табличек == журналов "граней"} -- сиквенсов [setval] -- вакуум отпадает, и unique гарантирован. доступ упорядочить на advisory.

как-то так

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

2-е может (?) быть полностью асинхронным. можно вообще снаружи читать и в этом же "снаружи" вести все требуемые журналы. [факультативно -- можно ли со стендбаев считывать]

есть другие предложения ?

vyegorov,

то ли вы меня не поняли
то ли я вас

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

vyegorovqwwq,

Вы сами говорите, что требуется “журнал [запись] достигнутого (уже отправленного) + журнал отсечки”.
В вашем случае у вас всегда 2 батча — "отправленные" и "в очереди".
нет. в моем случае никаких батчей пока нет.
еть 2 и только 2 записи в журналах.
/* которые вообще буду вести в сиквенсах. чтобы не вакуумировать.*/

-- они задают диапазон для последовательной работы.

а вычитываю я по N записей, или вовсе по K -- это вопрос организации транспорта. )последовательно [без каких--либо дополнительных журналов], или параллельно с регистрацией ошибок транспорта -- если последние предусмотрены)
я волен их организовать из промежутка в эти 2 грани.
vyegorovЯ предлагаю:
- сделать много батчей, что сделает их меньшего размера
- передавать данные батчами, т.е. либо весь батч, либо ничего
- принадлежность батчу оформить в виде дополнительного атрибута `batch_id` в вашей основной таблице, заполнять триггерной функцией.

внимание, вопрос:
чем гарантирован порядок коммита в порядке получения batch_id, если присвоение батчам -- синхронное ?

предложение p2 отвергнуто выше , ага.

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

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

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

я хочу уйти от всей этой гнилой кухни -- мне нужно знать, чего точно НЕТ в dirty -- и я в шоколаде. а вы мне какую--то кривую наколенную хрень от рукожопов предлагаете, простите за выражение.

авторзасунуть txid_current в саму таблицу событий
читать "таблицу данных"

qwwqvyegorov<>
внимание, вопрос:
чем гарантирован порядок коммита в порядке получения batch_id, если присвоение батчам -- синхронное ?

предложение p2 отвергнуто выше , ага.

тут более слабое сработает


в вызове
авторДобавил бы небольшую функцию, которая бы возвращала ID "открытого" (формируемого) батча. Если такового нет, то добавляла бы новую запись и возвращала ID (тут нужно через advisory упорядочиться).


можно скрестить с no wait + ~ try except в цикле с автономией на джобе тика нарезки. -- должно без горла получиться, но с вероятностью поиметь большие батчи.

-- т.е. это не возражение. "был неправ, вспылил" далее по тексту


остальное -- в силе. -- мне не нужно новых полей в данных. но и не нужно миллионных неразобранных табличек батчей при суточном простое -- должно хватать 2-х бигинтов -- верхнего и нижнего. С нижним всё ясно, а возможность в моменте выцепить верхнего у меня на уровне 0.25..0.35 по замерам с pg_stat_activity (я знаю выделенного писателя -- и фильтрую только его соединения. но перед тем как писать он долго читает. по снапшотам получается больше даже не зная писателя [других там нет]).

Maxim Bogukqwwq,

Я бы очень осторожно относился к использованию pg_stat_activity в таком контексте.
По моим воспоминаниям он асинхронный и показывает данные с задержкой.

--
Maxim Boguk
www.postgresql-consulting.ru
чего-то такого я ожидал, почему и не спешу с реализацией.

я так понимаю -- это вот про это

авторWhen using the statistics to monitor current activity, it is important to realize that the information does not update instantaneously. Each individual server process transmits new statistical counts to the collector just before going idle; so a query or transaction still in progress does not affect the displayed totals. Also, the collector itself emits a new report at most once per PGSTAT_STAT_INTERVAL milliseconds (500 ms unless altered while building the server). So the displayed information lags behind actual activity. However, current-query information collected by track_activities is always up-to-date.

т.к. писатель у меня -- известная и единственная хранимка -- я там вполне могу сделать PERFORM txid_current(); перед SELECT f(nextval()); -- т.е. обеспечить учёт по первому варианту. [с которого стартовал тут].

но тоже не хочется полагаться на случай. [поимки момента отсутствия других писателей]
т.ч. ищу пока способ -- скрестить последовательный замер {снапшотов, txid и max(id)} (для исчисления текущей грани по серии). но хочется так -- чтобы без вакуумов всей этой вспомогательщины постфактум.

Misha Tyurinqwwq,

пишите в pgq только айдишки (если не хотите все данные туда гнать, но и в таком случае оверхед будет не большой, имхо), оверхед тогда, по сути, нулевой, а весь мейнтаненс ("распухание-реиндекс") и отсутствие локов при вставках уже придумали там за вас (еще раз посмотрите там на "батчивание" внимательно и на ticker).

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

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

мне вместо миллионов ивентов хочется иметь 2 числа.
да, скользящих. и да -- в версионнике это сложно в таблицах -- т.ч. в сиквенсах.
к тому же второе число скорее всего буду вычислять из текущего снапшота и серии (тоже пухнущей скользящей, короткой) замеров (txid,max(id)). чтобы без зависимости от нагрузки. длинных писателей там нет. и чистить за собой сразу.

Misha Tyurin,

я ваще-то заметил про id.


но хочется иметь 2 числа вместо миллиона всегда.
"это просто красиво" (сс)

Misha Tyurin,

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



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

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

а хранить мне надо только txmax и max(id) до момента измерения -- когда оно таки провалится под горизонт видимости
вот только если бы ещё и хранить в памяти в приятной коллекции, а не в табличке -- вообще было бы чудно
но, думаю, тут лишнее что--то изобретать -- и так неплохо нарисовалось

Misha Tyurin> дятил

в детстве проблемы были у вас
а у вас они подзатянулись

Misha Tyurinнапишите реализацию в конкретных запросах sql/plpgsql вашей очереди, читать ваши предложения на произвольном языки совсем не понятно.умному -- достаточно


а подробный хенджоб -- это скучно, да и простынка получается солидная с тест--кейсом с многочисленными конкурентами.