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 со своей стороны ограничивает.дополнительно вывод.
Поясните, я не понял зачем вам изменять процедуры при failover.
Для потоковой репликации все реплики являются идентичными мастеру, даже бинарно идентичными. С потоковой репликацией вы в принципе не можете сделать разные хранимки на мастере и слейвах. Разница только в том, что на слейве пишущая хранимка вернёт ошибку что невозможно что-то писать в readonly базе. И при failover мастера вам необходимо проинструктировать приложение о том, на какой хост необходимо отправлять пишущие запросы. Впрочем, это можно сделать силами например haproxy, который будет простым скриптом опрашивать хосты на select pg_is_in_recovery() - кто ответил false тот и есть мастер.
primary key - определяет уникальную строку. Про то, что он может быть из одного поля речи нет. Если уникальность задают два поля - то и PK будет состоять из двух полей.
Плюс два foreign key, т.к. это значения-ссылки и будет хорошо, если база сможет проверять существование строк, на которые вы ссылаетесь.
например одна только на передачу, вторая только на прием сигнала, и будет ли увеличение скорости (обе гигабитые)?
В таком виде не имеет смысла, гигабит бывает только полнодуплексный, т.е. возможен одновременно и приём и передача данных. Это 10 и 100мбит ethernet могли быть полудуплексными.
Поймать всё что можно поймать - да, в php5 \exception, в php7 - \Throwable