Фамилия моего коллеги Лесовский всё-таки.
А так - ниже уже верно ответили, что это не проблема сама по себе. Значит что у вас горячих данных стало больше чем shared_buffers. Если буфера в много процентов от ram (75% например) - значит можно добавлять ещё памяти на сервере или наблюдать покамест за дисками. Если буфера меньше четверти памяти - то ни о чём не говорит. Если буфера около половины памяти - то измените в какую-нибудь сторону, или к 25% или к 75%. Половина памяти в буферах, половина в page cache - в итоге вы используете только половину памяти, потому что оба кеша себя дублируют по большей части.
Всё что лежит в datadir mysql - это части mysql, пока человек близко знакомый с исходниками этой СУБД (и именно вашего конфига, т.к. storage engine могут быть и добавлены) не сказал обратного.
Потому что у вас в запросе есть агрегирующая функция max и sum - весь запрос целиком получает группировку в одну единую группу.
Из-за того что упомянуты неагреггирующие поля - запрос невалиден. Но mysql такое может прощать если выключен ONLY_FULL_GROUP_BY. Что при этом будет в этих неагрегирующих полях - там будет что-нибудь. Никаких гарантий что именно.
Одна строка в результате объясняется как раз отсутствием group by в запросе. Запрос с агрегирующими функциями без явной группировки возвращает всегда одну строку, даже если выборка была из пустого множества. Поэтому может работать select count(*) from tablename - даже если таблица пуста, запрос вернёт всегда 1 строку с результатом агрегирующей функции.
Значит именно по такому пути - не существует.
Проверьте директорию на file_exists, посмотрите содержимое директории через scandir, совпадает ли регистр имён.
Где-то в пути ошибка. Или в правах, кстати. В мануале интересное замечание есть:
Note that is_file() returns false if the parent directory doesn't have +x set for you
И не появилось желания проверить результат is_file? Почему?
И что за современная мания к наскальной живописи? Неудобно же лечить по фотографиям.
Давно уже стиль php5.2 не встречал. При том с массивами в стиле 5.4+, что удивительно. Это я про человеческие spl_autoload и namespace.
Вопрос к вашим пакетам и их мейнтейнеру. Вообще затрудняюсь считать, что майнтейнер базы, удаляющий базу на минорном багфиксе задержится в этой роли. Но в принципе права у скриптов в пакете есть делать что угодно.
Пакеты из репозитория postgresql - нет, не удаляют. И есть отдельная проверка на совместимость версии.
wawa, у меня нет сейчас особого желания выяснять, настроили ли вы автовакуум должным образом (да и включен ли он у вас, а то бывают ненормальные выключающие автовакуум). Поэтому и упомянул вакуум как гарант своевременного прохода вакуума по табличке. Впрочем, не гарантирующий очищение старых версий строк, вдруг у вас ещё вагон долгих транзакций висят (включая реплики с hot standby feedback).
На адекватно-аггрессивных настройках автовакуума достаточно задержки между итерациями примерно в удвоенное время выполнения одной транзакции обновления чтобы не аффектить ни мастер ни реплики и для работы автовакуума быть достаточным.
На неясно каких настройках - штук 10 вызовов вакуума на табличку не помешают.
Функции mysql_* устарели фактически с релизом PHP5.0 (2004 год), официальное предупреждение о грядущем удалении появилось начиная с PHP5.5 (2013 год), в PHP7.0 были удалены (2015 год).
В 5.7 оно уже было выключено: https://dev.mysql.com/doc/refman/5.7/en/server-sys...
Если не включали сами руками - то соответственно ничего не заметите.