Про PostgreSQL …

Там хорошо, где нас нет …

Проснувшись ближе к вечеру (утром задолбала попа Грамота), открыл хабр и тупо стал созерцать картинку к топику про патчи к PostgreSQL:

c0a2b3b47dbe4bce8a31b7aa10980f6e_pg_patch

Набрал в поиске «element_alloc(HTAB *hashp, int nelem, in freelist_idx)» и вышел на файл postgrespro/postgres_cluster/blob/master/src/backend/utils/hash/dynahash.c.

Реально — используют int для nelem и freelist_idx.

Посмотрел что там дальше, после картинки — «есть основания полагать, что данные патчи будут интересны новичкам«.

А, ну понятно — это экскурсия для детей.

Вести с полей

Новая версия IBProvider-а, позволяющая работать с FB3 без fbclient.dll, вышла на финишную прямую.

Чтиво для размышлений

Вчера на firebirdnews выложили кучу ссылок на «паперсы» конференции FB в 2016-ом году.

Было интересно просмотреть доклад Firebird development process — Past, present and future.

Инфы, конечно, маловато. Это не Брукс со своим «Мифическим человеко-месяцом».

Но достаточно, чтобы задуматься.

Вести с полей

В процессе установки FB3 на тестовый сервер, обнаружил что он там когда-то уже пытался прижиться…

Обновление fbclient.dll (v3) на тестовом сервере IBProvider

Задумался… Четыре года прошло, ёлки-палки.

Про C++

Привет всем.

Полез в код Firebird (не напрягайтесь), чтобы посмотреть одну штуку.

Увидев код:

 (Arg::Gds(isc_auth_datalength)
  <<Arg::Num(charSize)
  <<Arg::Num(RemotePassword::SRP_SALT_SIZE * 2)
  <<"salt").raise();

Завис, а потом долго не мог вспомнить — «… зачем я сюда пришел?». А, ну да, полотенце жеж.

Забавно осознавать что я подобные конструкции игнорировал раньше. Наверное срабатывал защитный механизм.

Не, не круто. Надо так:

 Arg::Gds(isc_auth_datalength)
  <<Arg::Num(charSize)
  <<Arg::Num(RemotePassword::SRP_SALT_SIZE * 2)
  <<"salt"
  <<raise;

А еще круче:

 Arg::Gds(isc_auth_datalength)
  <<Arg::Num(charSize)
  <<Arg::Num(RemotePassword::SRP_SALT_SIZE * 2)
  <<"salt"
  <<raise_me;

Где raise_me это манипулятор, который перемещает (не копирует) состояние сконструированного объекта в выкидываемый объект исключения.

Пошел искать дальше искать, где эта зараза приводит имя пользователя к верхнему регистру.

Релиз IBProvider v3.32

Привет всем.

30 сентября были выложены бинарники нового релиза IBProvider-а. Сегодня выложили новости.

Основное — исправлена ошибка с блобами. Забавно, что несмотря на огромное количество тестов и внутренних проверок, эта бага прожила больше 6 лет и вылезла у клиента. В восемь вечера пришло письмо, в два часа ночи клиент получил исправленную и (номинально) оттестированную сборку. Чуть позже были созданы расширенные тесты и выложены релизные бинарники.

В общем, поупражнялся в поддержке.

Комбинаторика …

Привет всем.

В FB3 (13-протокол) сделали «упакованную» передачу для NULL-индикаторов. Раньше каждый индикатор передавался по-отдельности как SHORT-значение. Теперь все индикаторы передаются через битовый массив.

Ну ладно, реализовал этот формат. Теперь надо бы это все проверить. Желательно — через перебор максимально доступного диапазона.

Исходные данные — у нас F колонок, из них N с NULL-значениями.
(далее…)

Про отмену операций в Firebird (#2)

Привет всем.

Некоторое время назад, при прогоне тестов (с использованием пула подключений) на FB3, увидел интересный эффект — отмена операций в одном тесте может прерывать выполнение операций в следующем тесте.

Поставил я у себя в голове галочку, что на FB2.5 такого не было, и забил на эту проблему.

А сейчас вот увидел аналогичную проблему в рамках одного теста и на FB2.5 — мы вроде как хотим отменить Execute, а внезапно отменяется Commit:

[THR:010600] [test] RemoteFB__Connector::ConnectToDatabase ...OK
[THR:010600] [test] RemoteFB__Connector::StartTransaction ...OK
[THR:010600] [test] RemoteFB__Connector::StmtAllocate ...OK
[THR:010600] [test] RemoteFB__Connector::StmtPrepare ...OK
[THR:010600] [test] Run thread
[THR:004068] [thread] Execute command
[THR:010600] [test] Wait 1 sec
[THR:010600] [test] Cancel
[THR:010600] [test] Wait Thread
[THR:004068] [thread] RemoteFB__Connector::StmtExecute ...OK
[THR:010600] [test] Thread was stopped
[THR:010600] ERROR: [test] We wait the cancel exception!
[THR:010600] [test] RemoteFB__Connector::StmtDrop ...OK
[THR:010600] [test] RemoteFB__Connector::Commit ... FAILED
[THR:010600] ERROR: [RemoteFB.WORK.Cancel.01.StmtExecute.ptype__lazy_send] [Firebird] Операция была отменена.

Лопата в том, что:

1. Провайдер (и его собственный FB-клиент), отдает серверу Cancel-команду пока выполняется Execute. Про это было в предыдущем опусе со следующим примером.

2. В конце концов, тест (поток 010600) сначала выполняет Cancel, а потом Commit.

Вот такая вот засада с этим Cancel, которая (по факту) делает эту фичу бестолковой игрушкой. Сделанной для галочки.

Про списки объектов

Привет всем.

В потрохах Firebird многие вещи организованы в списки. Однонаправленные. Других я там не встречал. Ну организованы, так организованы. Вообщем-то, это их личные проблемы, которые снаружи не парят до определенного момента.

В процессе натягивания существующих тестов, созданных для собственного клиента FB (10-12 протоколы), на клиента для FB3 (13-ый протокол), задрался ждать пока завершится ничем неприметный тест. Полчаса работал. Полез в лог: в цикле три раза подряд создается/подготавливается/освобождается группа из 64999 запросов.

[THR:012440] [18.09.2016 10:44:40] ***********************************************
[THR:012440] [18.09.2016 10:44:40] * START TEST [RemoteFB.WORK.013.StmtAllocate.v2.ptype__lazy_send.011.check_release_of_dropped_stmts]
[THR:012440] [18.09.2016 10:44:40] *
[THR:012440] [18.09.2016 10:44:40] [test] Hello from test!
[THR:012440] [18.09.2016 10:44:40] [test] RemoteFB__Connector::ConnectToDatabase ...OK
[THR:012440] [18.09.2016 10:44:40] [test] RemoteFB__Connector::StartTransaction ...OK
[THR:012440] [18.09.2016 10:44:40] [test] Allocate statements ...
[THR:012440] [18.09.2016 10:46:31] [test] OK. We got the error.
[THR:012440] [18.09.2016 10:46:31] [test] 1. [Firebird] too many open handles to database
[THR:012440] [18.09.2016 10:46:31] [test] 2. [LCPI.IBProvider.3] [Подсистема: remote_fb.p13] Ошибка инициализации дескриптора запроса.
[THR:012440] [18.09.2016 10:46:31] [test] nMaxStatements: 64999
[THR:012440] [18.09.2016 10:46:32] [test] RemoteFB__Connector::ConnectToDatabase ...OK
[THR:012440] [18.09.2016 10:46:32] [test] RemoteFB__Connector::StartTransaction ...OK
[THR:012440] [18.09.2016 10:46:32] [test] -------------------------------- pass: 1
[THR:012440] [18.09.2016 10:46:32] [test] Allocate statements ...
[THR:012440] [18.09.2016 10:46:32] [test] ----
[THR:012440] [18.09.2016 10:48:37] [test] Drop statements ...
[THR:012440] [18.09.2016 10:48:37] [test] -------------------------------- pass: 2
[THR:012440] [18.09.2016 10:48:37] [test] Allocate statements ...
[THR:012440] [18.09.2016 10:56:57] [test] ----
[THR:012440] [18.09.2016 10:58:49] [test] Drop statements ...
[THR:012440] [18.09.2016 10:58:49] [test] -------------------------------- pass: 3
[THR:012440] [18.09.2016 10:58:49] [test] Allocate statements ...
[THR:012440] [18.09.2016 11:10:01] [test] ----
[THR:012440] [18.09.2016 11:11:51] [test] Drop statements ...
[THR:012440] [18.09.2016 11:11:51] [test] RemoteFB__Connector::Commit ...OK
[THR:012440] [18.09.2016 11:14:24] [test] RemoteFB__Connector::DetachDatabase ...OK
[THR:012440] [18.09.2016 11:14:24] *
[THR:012440] [18.09.2016 11:14:24] * REAL   TIME:17845270915   [00:29:44.5270915]
[THR:012440] [18.09.2016 11:14:24] * USER   TIME:155844999     [00:00:15.5844999]
[THR:012440] [18.09.2016 11:14:24] * KERNEL TIME:82524529      [00:00:08.2524529]
[THR:012440] [18.09.2016 11:14:24] * TOTAL  TIME:238369528     [00:00:23.8369528]
[THR:012440] [18.09.2016 11:14:24] *
[THR:012440] [18.09.2016 11:14:24] * STOP TEST [RemoteFB.WORK.013.StmtAllocate.v2.ptype__lazy_send.011.check_release_of_dropped_stmts]

А, ну да… Однонаправленный список объектов запросов.

Где-то год назад меня эта однонаправленность конкретно задолбала и пришлось выписать серверу лекарство — двунаправленный список, который гарантирует фиксированное время удаления элементов.

Наверное надо будет в свою тройку его тоже залить. Потому что FB2.5 (такой же отладочный как и тройка) с этим исправлением работает в два раза быстрее:

[THR:013768] [18.09.2016 11:19:07] ***********************************************
[THR:013768] [18.09.2016 11:19:07] * START TEST [RemoteFB.WORK.013.StmtAllocate.v2.ptype__lazy_send.011.check_release_of_dropped_stmts]
[THR:013768] [18.09.2016 11:19:07] *
[THR:013768] [18.09.2016 11:19:07] [test] Hello from test!
[THR:013768] [18.09.2016 11:19:09] [test] RemoteFB__Connector::ConnectToDatabase ...OK
[THR:013768] [18.09.2016 11:19:09] [test] RemoteFB__Connector::StartTransaction ...OK
[THR:013768] [18.09.2016 11:19:09] [test] Allocate statements ...
[THR:013768] [18.09.2016 11:21:38] [test] OK. We got the error.
[THR:013768] [18.09.2016 11:21:38] [test] 1. [Firebird] too many open handles to database
[THR:013768] [18.09.2016 11:21:38] [test] 2. [LCPI.IBProvider.3] [Подсистема: remote_fb.p12] Ошибка инициализации дескриптора запроса.
[THR:013768] [18.09.2016 11:21:38] [test] nMaxStatements: 64999
[THR:013768] [18.09.2016 11:22:06] [test] RemoteFB__Connector::ConnectToDatabase ...OK
[THR:013768] [18.09.2016 11:22:06] [test] RemoteFB__Connector::StartTransaction ...OK
[THR:013768] [18.09.2016 11:22:06] [test] -------------------------------- pass: 1
[THR:013768] [18.09.2016 11:22:06] [test] Allocate statements ...
[THR:013768] [18.09.2016 11:22:06] [test] ----
[THR:013768] [18.09.2016 11:24:37] [test] Drop statements ...
[THR:013768] [18.09.2016 11:24:37] [test] -------------------------------- pass: 2
[THR:013768] [18.09.2016 11:24:37] [test] Allocate statements ...
[THR:013768] [18.09.2016 11:26:27] [test] ----
[THR:013768] [18.09.2016 11:28:56] [test] Drop statements ...
[THR:013768] [18.09.2016 11:28:56] [test] -------------------------------- pass: 3
[THR:013768] [18.09.2016 11:28:56] [test] Allocate statements ...
[THR:013768] [18.09.2016 11:30:47] [test] ----
[THR:013768] [18.09.2016 11:33:16] [test] Drop statements ...
[THR:013768] [18.09.2016 11:33:16] [test] RemoteFB__Connector::Commit ...OK
[THR:013768] [18.09.2016 11:33:50] [test] RemoteFB__Connector::DetachDatabase ...OK
[THR:013768] [18.09.2016 11:33:50] *
[THR:013768] [18.09.2016 11:33:50] * REAL   TIME:8831512364    [00:14:43.1512364]
[THR:013768] [18.09.2016 11:33:50] * USER   TIME:134316861     [00:00:13.4316861]
[THR:013768] [18.09.2016 11:33:50] * KERNEL TIME:131352842     [00:00:13.1352842]
[THR:013768] [18.09.2016 11:33:50] * TOTAL  TIME:265669703     [00:00:26.5669703]
[THR:013768] [18.09.2016 11:33:50] *
[THR:013768] [18.09.2016 11:33:50] * STOP TEST [RemoteFB.WORK.013.StmtAllocate.v2.ptype__lazy_send.011.check_release_of_dropped_stmts]

Но это надо раз десять тест запустить, чтобы созреть для такого подвига.

Are you prepared for Firebird 3?

Привет всем!

Увидел сегодня %subj% на firebirdnews.

Задумался…

А ведь пять лет прошло, Карл. Пять лет!

« Предыдущие записи