hi all

Изабэлло выдумывать, как в каждом коннекте приостановить скрипт, "до особого распоряжения". И чтобы он проверял это распоряжение не чаще 1 раза в N секунд.

Необходима UDF'ка, которую можно вызвать изнутри PSQL-кода с требованием "а ну спать N секунд!", и чтобы при этом сервак не грузился от этого спящего коннкета. Ставить VS и выдумывать велосипед - в лом, да и времени нет.

Если есть у кого готовая dll - вышлите, плз, на p519446 ат yandex.ru
Нужно для одного сверхважного теста ;)

ЗЫ. А встроенная ф-ция в ФБ, видимо, не появится никогда :(

если оно,

спс!

Dimitry SibiryakovСтранно, что он решил использовать UDF, а не свой любимый трюк с таймаутом транзакции и
select for update with lock.Это тоже сначала было, но не пропёрло на CS, всё в ступор влетело при числе аттачей > 50 :-) Точный сценарий уже не вспомню, но попозжее воспроизведу.

Ситуация следующая. При прогоне fbt-теста для CORE-1249 закралось сомнение, что с шатдауном в CS "чё-то не того": сообщение от IBProdiver'a какое-то лезет, да и базу в онлайн не переводит. Начал рыть дальше - и натолкнулся в трейсе на то, что уже после шатдауна в базе может шевелиться процесс GC (в арх-ре SS). Хорошо ещё, что пока GC там шевелится, управление в вызывающую среду из fbsvcmgr'a не возвращается.
Дальше - больше: сделал примитивно-корявый тест с запуском 20 молотилок, уже на SuperClassic'e - а он взял и подвис в усмерть. Сделал еще пару раз на CS - и получил в логах нескольких (не всех) молотилок В общем, ваяю тест, который будет делать следующее:

0) асинхронный старт трейса силами fbsvcmgr'a
1) асинхронный старт N сеансов ISQL;
2) каждый после установки своего коннекта должен подождать без грузилова процесса сервера до тех пор, пока не увидит, что влезли все остальные (т.е. он "знает", сколько их должно быть в итоге);
3) как только "все тута" - так сразу и "понеслось": делаем дружно insert'ы, 1 млн строк
4) а в это время из-за угла, через пару секунд, выглядывает еще один fbsvcmgr и делает шатдаун ( action_properties dbname %dbpath%%dbname% prp_shutdown_mode prp_sm_full prp_force_shutdown 0 ). Батник при этом обязательно ждёт возврата управления из fbsvcmgr'a, т.е. тут вызов должен быть синхронным - в отличие от пп 0 и 1.
5) запускается еще раз fbsvcmgr с целью определить ID трейса, после чего - дается команда action_stop_trace. После этого тупо жду 7-10 сек - в надежде, что лог трейса полностью за это время запишется на диск.
6) ищу в логе трейса первое упоминание слова 'shutdown', запоминаю номер этой строки L
7) ищу далее в этом же логе ПОСЛЕ строки L любое из слов {ATTACH_DATABASE START_TRANSACTION COMMIT_TRANSACTION PREPARE_STATEMENT EXECUTE_STATEMENT_START EXECUTE_STATEMENT_FINISH CLOSE_CURSOR FREE_STATEMENT} -- но только чтобы там не было 'FAILED', т.к. это не интересует.

ЗЫ. UDF - всё равно будет когда-нить полезной, но я таки нашёл вспомнил, как выкрутиться без неё. Сейчас допиливать буду. Одну хрень уже нарыл (странности в логе коннектов после шатдауна, см. выше), может еще чего вытащу - ждите новостей (в трекере, наверное).

Симонов Денис,

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