Что вы сделали для того, чтобы изменённые переменные окружения устанавливались заново при следующей авторизации пользователя? В PATH очевидно отсутствует место куда вы поставили бинарники базы.
Chvalov, по приведённому фрагменту не видно, что пространства имён не используются. Выведите var_dump(__NAMESPACE__); перед try, например.
Поймать всё что можно поймать - да, в php5 \exception, в php7 - \Throwable
Не во всех месяцах есть 31 день. И Postgresql об этом знает. Даже 29 день не всегда бывает. И об этом база тоже знает. И даст за такое безобразие как 31 ноября ошибку.
Выведите в notice переменные, посмотрите какие именно констрейнты создаются. Раз триггер ведёт себя странно - значит отлаживайте триггер.
Проще всего такое поймать если ходить в базу через баунсер в режиме пула транзакций. Где большим и заметным текстом написано: серверные prepared statements в пуле транзакций не поддерживаются. При том транзакционный пул выгоднее сохранения серверных prepared и потому рекомендация включить эмуляцию prepared statements в PDO (она дефолтно включена)
Explain запроса с одной таблицей так выглядеть не может. Либо вы показываете план не того запроса о котором говорите.
Плюс покажите show constraint_exclusion и (в psql) \d events2016m11 для примера того, что table constraint у вас есть.
Как обычный представитель подвида btree индексов для range поиска. Поиском от корня находим нужный MarketName, идём до минимальной подходящей даты и вычитываем все узлы до максимальной подходящей. С полученными id лезем в primary key и вычитываем непосредственно данные таблицы (т.к. innodb всегда кластеризован по первичному ключу и все вторичные индексы ссылаются на PK, а не на расположение данных в датафайлах)
Я проголосовал за изменение сложности вопроса на senior. exit, echo - не функции, а конструкции языка. Поэтому это где-то в потрохах Zend движка языка. Возможно глубоко в потрохах.
Вероятно у вас где-то до этого файла объявлялись такие константы. Вообще странная мысль делать константы с текстом регулярок с такими именами в глобальном пространстве имён.
Несортированным списком: mysql, postgresql, oracle, mssql.
Вот sqlite dba я себе как-то не представляю. Самая распространённая субд, но не серверная и базы у неё очень маленькие и потому проблем не дают.
Что востребовано смотрите вакансии. Интересные проекты есть для всех этих 4 СУБД, а я не изучал реалии трудового рынка DBA.
Следовательно, вы не перезагрузились. Если под "перезагрузился" вы подразумевали reload - то значит не проверили логи базы, там было извещение о том, что изменение параметра не применено, т.к. требует рестарта..
Уточнение обозначает, что изменение этого параметра возможно только при старте базы. На живую не изменить.
Ну и надеюсь вы параметр всё-таки раскомментировали.
Разделять запись от чтения правильнее именно на приложении. Потому что именно приложение знает, будет ли операция что-то модифицировать и насколько критична актуальность данных. Может быть и 100% читающий запрос, который можно вызывать только на мастере. (например, потому что ставить ещё и синхронную реплику оказалось для проекта хуже)
1025 > 1024.
Можете проверить запросом show track_activity_query_size что настройка изменилась.
Возможно ваш GUI со своей стороны ограничивает.дополнительно вывод.
